How to Make IoT Sensitive to Privacy?

An Approach Based on ODRL and Illustrated With WoT TD

Zakaria Maamar

1 a

, Amel Benna

2 b

, Yang Xu

3 c

, Mohamed Adel Serhani

4 d

Minglin Li

, Huiru Huang

, Wassim Benadjel

and Nacereddine Sitouah

College of Computing and IT, University of Doha for Science and Technology, Doha, Qatar

Department of Multimedia and Information Systems, CERIST, Algiers, Algeria

School of Computer Science, Fudan University, Shanghai, China

College of Computing and Informatics, University of Sharjah, Sharjah, U.A.E.

Computer Science Faculty, USTHB, Algiers, Algeria

Department of Electronics, Information and Bioengineering, Polytechnic University of Milan, Milan, Italy

Keywords:

Internet-of-Things, ODRL, Privacy, WoT TD.

Abstract:

Despite the multiple advantages of the Internet-of-Things (IoT), many users are still skeptical considering

IoT as another disruptive information and communication technology that is “silently” invading their privacy

with the risk of having their habits, preferences, and choices exposed publicly. To mitigate this silent in-

vasion, this paper looks into innovative ways of making IoT sensitive to privacy by ﬁrst, allowing users to

explicitly express what is permitted, forbidden, and obliged over their personal data using the Open Digital

Rights Language (ODRL), and second, adjusting things’ speciﬁcations like the Web-of-Things Thing Descrip-

tion (WoT TD), so that things would act according to these users’ permissions, prohibitions, and obligations.

A system implementing and demonstrating the blend of ODRL with WoT TD is presented based on a case

study capturing privacy concerns in a center for elderly people.

1 INTRODUCTION

Despite the tremendous advances in Information

and Communication Technologies (ICTs), Privacy re-

mains one of the persistent concerns that constitutes

a major obstacle to the expansion and adoption of

many ICTs (Silva et al., 2021). Indeed, poor han-

dling of privacy could have severe consequences on

both persons and businesses. To avoid similar situ-

ations and mitigate their consequences, many initia-

tives exist with focus, in this paper, on Open Digital

Rights Language ODRL. ODRL is used to express that

“something is permitted, forbidden, or obliged, pos-

sibly limited by some constraints” (W3C, 2018).

To exemplify ICTs that are revolutionizing the

way contextualized services are provisioned to users,

we consider the Internet-of-Things (IoT, (Gupta and

https://orcid.org/0000-0003-4462-8337

https://orcid.org/0000-0002-9076-5001

https://orcid.org/0000-0002-0958-8547

https://orcid.org/0000-0001-7001-3710

Quamara, 2020)). From autonomous farming equip-

ment to driverless vehicles and wearable health moni-

tors, IoT’s beneﬁts and uses are endless. It is predicted

that 41 billion IoT devices will exist by 2027 and

that 70% of vehicles will be connected to the Internet

by 2023

. However, despite all the beneﬁts and uses

of IoT, privacy will slow down IoT’s “silent” invasion

into people’s lives (Mohanta et al., 2021). Whether

visible or invisible, things collect details about peo-

ple’s (and even about other things) habits, prefer-

ences, etc. Although this collection could be subject

to approvals, requesting approval for every single de-

tail and continuously would become over time cum-

bersome and inefﬁcient. To address privacy concern

in an IoT ecosystem, we examine in this paper how

to make things “aware” of their rights of and duties

towards the data they get, and the actions they per-

form over these data. Could we blend ODRL with any

appropriate thing description-language to achieve this

awareness and hence, have a new generation of things

www.vxchnge.com/blog/iot-statistics.

Maamar, Z., Benna, A., Xu, Y., Serhani, M., Li, M., Huang, H., Benadjel, W. and Sitouah, N.

How to Make IoT Sensitive to Privacy? An Approach Based on ODRL and Illustrated With WoT TD.

DOI: 10.5220/0012047600003538

In Proceedings of the 18th International Conference on Software Technologies (ICSOFT 2023), pages 233-240

ISBN: 978-989-758-665-1; ISSN: 2184-2833

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

233

sensitive to privacy? Being W3C de facto standard to

describe things, we adopt the World-of-Things Thing

Description (WoT TD) to concretize this blend.

WoT TD abstracts a thing, whether physical or

virtual, into an entity that would logically reside

in an ecosystem of things and would engage in in-

teractions with these things. To blend ODRL with

WoT TD, we proceed with (i) examining separately

the model of each speciﬁcation, (ii) identifying poten-

tial overlaps/correspondences between the 2 models’

constructs, and ﬁnally, (iii) using these constructs to

make WoT TD-based things sensitive to ODRL-based

rights and duties. Section 2 is an overview of IoT,

ODRL, and WoT TD. Section 3 is the core of the paper

by presenting a case study and conceptualizing and

operationalizing the blend of ODRL with WoT TD for

an IoT sensitive to privacy. Section 4 concludes the

paper and discusses future work.

2 BACKGROUND

This section presents IoT, ODRL, and WoT TD.

2.1 Overview of IoT

A good number of works on IoT exist, which in fact

does not help deﬁne IoT from a unique perspective

(e.g., (Abdmeziem et al., 2016), (Barnaghi and Sheth,

2016), and (Taivalsaari and Mikkonen, 2017)). For

illustration, Abdmeziem et al. present IoT character-

istics and enabling technologies (Abdmeziem et al.,

2016). The former include distribution, interoperabil-

ity, scalability, resource scarcity, and security. And,

the latter include sensing, communication, and actu-

ating, and are mapped onto a 3-layer IoT architecture

referred to as perception, network, and application.

In (Barnaghi and Sheth, 2016), Barnaghi and Sheth

discuss IoT’s requirements and challenges. Require-

ments are related to quality, latency, trust, availabil-

ity, reliability, and continuity that should impact efﬁ-

cient access and use of IoT data and services. And,

challenges result from today’s IoT ecosystems that

feature billions of dynamic things that make existing

search, discovery, and access techniques inappropri-

ate for IoT data and services. Finally, Qin et al. deﬁne

IoT from a data perspective as “In the context of the

Internet, addressable and interconnected things, in-

stead of humans, act as the main data producers, as

well as the main data consumers. Computers will be

able to learn and gain information and knowledge to

solve real world problems directly with the data fed

from things. As an ultimate goal, computers enabled

by the Internet of Things technologies will be able to

sense and react to the real world for humans” (Qin

et al., 2016).

2.2 Overview of ODRL

ODRL is an example of Rights Expression Lan-

guages (REL) that provides a ﬂexible and interop-

erable information model, vocabulary, and encoding

mechanisms to represent statements about the poten-

tial uses of assets. An asset is an identiﬁable resource

(or collection of resources) such as data/information,

content/media, applications, and services. The ODRL

information model is available at www.w3.org/TR/

odrl-model and whose main constructs are:

• Policy could include one to many permission, pro-

hibition, or duty rules. First, Permission allows an

action over an asset if all constraints are satisﬁed

and all duties are fulﬁlled. Second, Prohibition

disallows an action over an asset if all constraints

are satisﬁed. And, Duty is the obligation to exer-

cise an action that over an asset or not.

• Party is an entity or collection of entities that

could correspond to a person, group of persons,

organisation, or agent. A party can fulﬁll differ-

ent roles including assigner (issuer of the rule),

and assignee (recipient of the rule),

• Constraint is used to reﬁne the speciﬁcation of an

action and a party/asset collection or to declare

conditions applicable to a rule.

In JSON-LD Listing 1, the assigner (line 6) in

charge of an asset, movie1 (line 5), refers to a pol-

icy labelled as agreement (line 3) consisting of one

permission rule and one prohibition rule. The per-

mission rule (line 4) that is concerned with display

action (line 8) that an assignee, smart TV (line 7),

will execute subject to satisfying the constraint of

not enabling the permission rule for more than

4 hours (lines 10-13). The prohibition rule (line 14)

that is concerned with digitize action (line 18) that is

associated with the same assignee (line 17). Should

the assignee execute this action, then the remedy

would be to apply the action anonymize (line 20) to

the asset that is movie1 (line 21).

Listing 1: Excerpt of movie’s ODRL speciﬁcation.

1 {" @c o n t e xt ": " htt p : // w ww . w 3 . or g / ns / o drl . js o n ld "

2 " ui d ": " ht t p : // e x a m ple . co m / p o licy : 0 1 " ,

3 " @ typ e " : " A g r e e ment " ,

4 " p e r m i ssion " : [{

5 " ta r get " : " htt p : // ex a m ple . co m / a sse t : mo v ie 1 ",

6 " as s i g ner ": " h ttp : // exa m p l e . c om / Mo v ie 1 P art y :

org " ,

7 " as s i g nee ": " h ttp : // exa m p l e . c om / sma rt - TV " ,

ICSOFT 2023 - 18th International Conference on Software Technologies

234

8 " ac t ion " : " d i spl a y " ,

9 " co n s t r a i nt ": [{

10 " le f t O p e r a n d " : " m e t e r e d T ime ",

11 " op e r a tor ": " it eq " ,

12 " ri g h t O p e r a n d " : { " @va l u e ": " P 4H" ,

" @ t ype " : " xsd : dur a t i o n " },

13 " u n it " : " ht tps : // www . w i k idat a . org /

wi ki / Q2 523 5 "}]}] ,

14 " p r o h i b i tion ": [{

15 " ta r get " : " htt p : // ex a m ple . co m / a sse t : mo v ie 1 ",

16 " as s i g ner ": " h ttp : // exa m p l e . c om / Mo v ie 1 P art y :

org " ,

17 " as s i g nee ": " h ttp : // exa m p l e . c om / sma rt - TV " ,

18 " ac t ion " : " di g i t i ze ",

19 " re m edy " : [{

20 " ac t ion " : " an o n y m i z e ",

21 " ta r get " : " htt p : // ex a m ple . co m / a sse t : mo v ie 1 "}

]}]

22 }

2.3 Overview of WoT TD

WoT TD is a central building block in the W3C WoT

and can be considered as a Thing’s entry point (W3C,

2020). It describes the metadata and interfaces of

things, where a thing is an abstraction of a physi-

cal or virtual entity that provides interactions to and

participates in the WoT. Thing Descriptions provide a

set of interactions based on a limited vocabulary that

makes it possible both to integrate diverse devices and

to allow diverse applications to interoperate. Fig. 1 is

an excerpt of WoT TD model that is built upon 4 Vo-

cabulary parts having each a namespace: (i) core TD

Vocabulary deﬁnes the interaction model, (ii) Data

Schema Vocabulary describes a common subset of

terms deﬁned in a JSON Schema, (iii) WoT Security

Vocabulary identiﬁes the conﬁguration of the security

mechanisms, and (iv) Hypermedia Controls Vocabu-

lary provides a representation for Web links and Web

forms that a Thing exposes to potential end-users.

In Fig. 1, InteractionAffordance is how end-users

and/or peers could interact with a Thing: Properties

of type PropertyAffordance allows to sense and con-

trol parameters, Actions of type ActionAffordance al-

lows to invoke physical processes, and Events of type

EventAffordance allows to asynchronously push com-

munications such as notiﬁcations, discrete events, and

streams of values to receivers.

Listing 2 shows a WoT TD instance of a lamp

Thing referred to as MyLampThing. Thanks to this

description, we know that there exists one Property

affordance with the title status (line 8), an Action af-

fordance is speciﬁed to toggle (lines 12-13) the switch

status, and an Event affordance known as overheat-

ing (line 15) that enables a mechanism for asyn-

chronous messages to be sent by a Thing. The list-

ing also speciﬁes a basic security scheme requiring a

username and password for access (line 5).

Listing 2: Excerpt of lamp’s WoT TD speciﬁcation.

1 {" @c o n t e xt ": " htt p s : // www . w 3 . org /2 0 1 9 / wo t / td /v1

2 "id ": " urn : de v : ops : 3 2 4 7 3 - WoT Lam p - 1 2 3 4 ",

3 " t itl e " : " M y L a m p T h ing ",

4 " s e c u r i t y D e f i n i t i o n s " : {

5 " ba s i c _sc ":{" sc h e me " :" b a sic " , " in " : " h eade r "}

6 " se c u r ity ": [ " b asic _ s c " ] ,

7 " pr o p e r t i es ": {

8 " st a tus " : {.. . " f orm s " : [{" hr ef " : " ... " }]}

9 " ac t ions " : {

10 " to g gle " : {" for m s ": [{" h ref " : ".. . "}]}},

11 " ev ents " :{

12 " ov e r h e a t i n g " :{.. .}}

13 }

To the best of our knowledge, there are no research

that speciﬁcally examine the blend of ODRL with

thing descriptions/WoT TD.

3 ODRL-WOT TD APPROACH

After presenting a case study that sheds light on pri-

vacy concerns, the rest of this section conceptualizes

and operationalizes ODRL/WoT TD blend. Different

WoT TD and WoT TD speciﬁcations and screenshots

are used for illustration purposes.

3.1 Case Study

To illustrate ODRL/WoT TD blend for an IoT sensi-

tive to privacy, our case study targets a long-term

care center for elderly people. On different occasions,

these people get together in the living room to watch

movies among other activities. First, we treat movie

as an asset whose use needs to be regulated. And,

we treat smart TV as a thing that would act upon

movies through speciﬁc actions. The smart TV is syn-

chronized with the elderly people’s smartphones mak-

ing them a second thing in the case study that would

act upon movies sometimes through the smart TV.

When playing movies, the smart TV would record

details like titles, ratings, and years of release. While

these details seem insigniﬁcant for elderly people,

third parties like drug companies could use them

to develop targeted awareness campaigns that could

make these people subscribe to some healthcare pro-

grams. To prevent the smart TV from collecting de-

tails for unauthorized uses and/or sharing details with

unapproved third-parties, we resort to ODRL poli-

cies. Our objective is to ensure that the smart TV

How to Make IoT Sensitive to Privacy? An Approach Based on ODRL and Illustrated With WoT TD

235

Figure 1: Excerpt of WoT TD information-model ((W3C, 2020)).

designated as assignee according to ODRL terminol-

ogy, is aware of the permission, duty, and prohibi-

tion rules impacting movies and hence, sensitive to

any privacy concerns. To this end, we specify the as-

signee/smart TV in WoT TD considering these per-

missions, duties, and prohibitions. This would make

the smart TV’s actions compliant with ODRL policies

by for instance, sharing a movie’s title because of a

permission rule, enforcing a movie’s rating because of

a duty rule, and scheduling a movie’s viewing hours

because of a prohibition rule. The way we correspond

asset-assignee:action to thing:action and identify and

specify smart TV and smartphone is given next.

3.2 Approach Conceptualization

Fig. 2 conceptualizes the approach to blend ODRL

with WoT TD by carrying out some operations at

design-time (d) and the rest at run-time (r). Dur-

ing this blend, 2 software engineering best-practices

are applied. First, ODRL speciﬁcations of assets

and WoT TD speciﬁcations of things remain loosely

coupled allowing their potential re-uses in other

case studies without being restricted to speciﬁc ones.

Second, this loosely coupling allows achieving the

separation of concerns principle (Kambayashi and

Ledgard, 2004).

Operations at Design Time. 2 stakeholders, asset

owners and IoT engineers, are involved. The former

use the asset-deﬁnition module to identify the neces-

sary assets, e.g., movie, according to the case study’s

needs and requirements and to specify these assets

in ODRL. During the speciﬁcation of assets (1

2 ODRL constructs are deemed critical with respect

to the policies linked to these assets: assignee and

action. Upon receipt of the asset speciﬁcations from

the asset-deﬁnition module, the extractor module (2

)

extracts the assignee and action constructs along with

other associated details like policy and constraints and

makes them available to the IoT engineer. This one

uses the thing-deﬁnition module to ﬁrst, specify fu-

ture things and their actions that would match as-

signees and actions (3

), respectively, and second,

identify additional things that would be deemed nec-

essary with respect to the case study’s needs and re-

quirements (4

). In all cases, things will be speciﬁed

in WoT TD. Since the additional things could act upon

assets, the IoT engineer would inform the owners of

these assets. The objective is to adjust these assets’

ODRL speciﬁcations, as they see ﬁt (5

). More details

about developing thing speciﬁcations and adjusting

asset speciﬁcations are given in Section 3.3. With re-

spect to the elderly-center case study, smart TV would

be associated with operation (3

) and smartphone

would be associated with operations (4

) and (5

Operations at Run Time. Upon submitting both as-

set speciﬁcations and thing speciﬁcations to the de-

ployer module, this one makes things and assets re-

side in the cyber-physical ecosystem as either phys-

ical or digital entities so they act according to their

respective speciﬁcations. In conjunction with this de-

ployment, the deployer module informs the monitor-

ing module about the things and assets so that it an-

alyzes their behaviors and notiﬁes the IoT engineers

and asset owners, respectively, of any potential de-

viations from the prescribed thing and asset speciﬁ-

cations. For instance, a thing acting as an assignee

does not commit to a duty policy or violates a prohi-

bition policy. More details about run-time operations

are presented in Section 3.4.

3.3 Thing Identiﬁcation and

Speciﬁcation

As stated earlier, there exist 2 ways to identify an

IoT ecosystem’s future things, whether physical or

digital, that could act upon assets. An ecosystem

ICSOFT 2023 - 18th International Conference on Software Technologies

236

Thing

specifications

Asset definition

1

d

Asset

specifications

Case study

WoT TD

ODRL

Assets

Notification

Asset

owners

Design time Run time

Chronology of

operations

Legend

i Repository

Ecosystem

Thing definition

3

d

2

d

Extractor

IoT-related

details

Things

1

r

Deployer

Monitor

Update

(Thing,Asset)

deployment

Tracking

Asset specifications

IoT

engineers

4

d

5

d

Notification

Figure 2: Representation of ODRL-WoT TD approach.

could be our elderly care-center. The ﬁrst way taps

into the assignee construct in all ODRL speciﬁcations

where every assignee becomes an independent thing

(Thing as per Fig. 1). The second way taps into the re-

quirements of the under-development IoT applications

of the case study like the elderly center. Indeed, the

IoT engineer identiﬁes new things not reported in the

ODRL speciﬁcations, as he sees ﬁt. Let us illustrate

the ﬁrst way of thing identiﬁcation. Here the IoT en-

gineer proceeds in 2 steps:

1. In the ﬁrst step, the IoT engineer uses some details

extracted from Listing 1 to convert the assignees,

e.g., smart TV, into things and to put together a

preliminary version of these things’ WoT TD spec-

iﬁcations like the one shown in Listing 3. The

IoT engineer also refers to details from Listing 1

and how these things are used in daily life to insert

some properties, e.g., status (line 7), and some

actions, e.g., switchON, switchOFF, and display,

(lines 23, 24, and 25-31, respectively), into their

WoT TD speciﬁcations with focus on ActionAffor-

dance as per Fig. 1. For those actions, e.g., dis-

play, already reported in Listing 1 and then, List-

ing 3, it is required that they are not part of any

prohibition policies in the assets’ ODRL speciﬁca-

tions. Otherwise, the actions will be treated differ-

ently for instance, discarded at the IoT engineer’s

own discretion.

2. In the second step, the IoT engineer ensures

that the actions in Listing 3 would comply

with their existing constrained deﬁnitions in List-

ing 1, should these actions already exist in the

ODRL speciﬁcations. For instance, the IoT en-

gineer ensures the compliance of the display ac-

tion with its associated constraints by includ-

ing in Listing 3 ﬁrst, an additional action, sus-

pend (line 32), along with its necessary parame-

ters, displayValidityPeriod and movie-id (lines 34-

35) to put displaying movies on hold, and second,

additional properties, possibleMovies (line 21) for

the list of possible movies that this TV can display

and dispTime (lines 8-12) for the time elapsed

since the permission rule to display a movie is ac-

tivated.

Still in the ﬁrst way of thing identiﬁcation with

focus here on the prohibited actions with remedy,

e.g., digitize in Listing 1. Should the IoT engineer

decide on retaining these actions in things’ WoT TD

speciﬁcations, e.g., digitize in Listing 3 (line 40), then

the remedy actions must be included in these speciﬁ-

cations, e.g., anonymize in Listing 3 (line 41). Finally,

for those prohibited actions without remedy, they are

automatically discarded from the analysis of assets’

ODRL speciﬁcations. These actions cannot be exe-

cuted.

Listing 3: Excerpt of smart TV’s WoT TD speciﬁcation.

1 {" @c o n t e xt ": " htt p s : // www . w 3 . org /2 0 1 9 / wo t / td /v1

2 "id ": " ht tp : // e x a mpl e . com / sm art - tv " ,

3 " nam e ": " S m art T V " ,

4 " s e c u r i t y D e f i n i t i o n s " : {.. . },

5 " s e c urit y " : [ . .. ] ,

6 " p r o p e rties " :{

7 " st atus " :{... }

8 " di s p T ime ":{

9 " ob s e r v a b le ": tru e ,

10 " de s c r i p t i o n " : " d i spla y ti m e o f mov i e by

sm a rt TV " ,

11 " t y pe " : " in t e ger ",

12 " mi n i mum " : 0 ...},

13 " mo v i e _ d e t a i l s " : {

14 " t i tle " : " de t a i ls ",

15 " ob s e r v a b le ": tru e ,

16 " t y pe " : " ob j ect " ,

17 " de s c r i p t i o n " : " d e tail s of t he m o vie

dis p l a y e d ",

18 " pr o p e r t i es ": {

19 " Dat e _ o f _ r e l e a s e " : {" ty p e ": " Da t e ",

How to Make IoT Sensitive to Privacy? An Approach Based on ODRL and Illustrated With WoT TD

237

...},

20 " Du r a t ion ":{" ty pe " : " in t e ger ", ... }...

}},

21 " po s s i b l e M o v i e s " :{... }, .. .},

22 " a c tion s " :{

23 " sw i t c hON ":{. ..},

24 " sw i t c h OFF ":{...},

25 " di s p lay " :{

26 " de s c r i p t i o n " : " D i spla y mov i e ",

27 " i n put " : {" d i s p layTim e " : " int e g e r ", "

movie - id ": " an y U RI "},

28 " f o rms " : [{

29 " h r ef " : " htt p : // ex a mple . co m / sm ar t - tv /

dsp{? di s l a y T i m e , movie - id}" ,

30 " h t tp : m ethod N a m e " : " P O ST " ,

31 " co n t e n t T y p e " : " a p p l i c a t ion / j son "}]}

32 " su s p end " :{

33 " de s c r i p t i o n " : " S u spen d mov i e ",

34 " i n put " :{" displayV a l i d i t y P e r i o d " : " 2 4 0" ,

35 " movie - id " : " htt p : // exa m p le . com / as set :

mo v ie 1 "},

36 " f o rms " : [{

37 " h r ef " : " htt p s : // SM A R TTV . e x a mpl e . com /

su s p e nd{? d i s p l a y V a l i d i t y P e r i o d ,

movie - id }" ,

38 " h t tp : m ethod N a m e " : " P O ST " ,

39 " co n t e n t T y p e " : " applic a t i o n / js on "},

...},

40 " di g i t ize ":{. ..},

41 " an o n y m ize ":{...}... }

42 }

We now discuss the second way of thing identi-

ﬁcation. Contrarily to smart TV that is speciﬁcally

reported in movie’s ODRL speciﬁcation, the IoT engi-

neer decides on having extra things, e.g., remote con-

trol and smartphone, that would allow to satisfy the

needs and requirements of the case study’s under-

development IoT applications. To this end, the IoT en-

gineer develops several WoT TD speciﬁcations from

scratch like Listing 4 for smartphone. In this listing,

many actions exist such as controlTV (line 21) that

conﬁgures a smart TV’s main functionalities from the

smartphone, displayOnTV (line 22) that switches dis-

playing movies from the smartphone to a smart TV,

and digitize (line 23) that produces a digital copy of

the displayed movies on the smartphone.

Listing 4: Excerpt of smartphone’s WoT TD speciﬁcation.

1 {" @c o n t e xt ": " htt p s : // www . w 3 . org / 2 0 1 9 / wo t / td /v 1

2 "id ": " ht tp : // e x a mpl e . com / S m a r t phone /0 01",

3 " nam e ": " R e m o t e C o n t r o l " ,

4 " s e c u r i t y D e f i n i t i o n s " : {.. . },

5 " s e c urit y " : [ . .. ] ,

6 " p r o p e rties " :{

7 " st a tus " :{... },

8 " co n t a c t s L i s t " :{

9 " wr i t a ble ": true ,

10 " ob s e r v a b le ": tru e ,

11 " f o rms " : [{

12 " h r ef " : " ht tps : // S m artPh o n e . exam p l e

. c om / contact s L i s t "}]}, ... },

13 " a c tion s " :{

14 " sw i t c hON ":{. ..},

15 " ma n a g e C o n t a c t " :{

16 " f o rms " : [{

17 " h r ef " : " ht tps : // S m artPh o n e . exam p l e

. c om / contac t L i s t " ,

18 " h t tp : m ethod N a m e " : " P O ST " ,

19 " co n t e n t T y p e " : " a p p l i c a t ion / j son "}]

20 " do w n l o a d A p p " :{.. .},

21 " co n t r o lTV ":{...},

22 " di s p l a y O n T V " :{.. .},

23 " di g i t ize ":{. ..}, ... }

24 }

After specifying the extra things, i.e., remote con-

trol and smartphone, the IoT engineer decides on al-

lowing smartphones to act on movies by displaying

their trailers, for example. To accommodate this dis-

play in compliance with the existing ODRL speciﬁca-

tion of movie (Listing 1), the owner adjusts this spec-

iﬁcation as per Listing 5 where the type is no longer

agreement but policy

(line 3), smartphone is added

as an assignee (line 7), and some properties are com-

pacted such as target (line 4).

Listing 5: Excerpt of movie’s adjusted ODRL speciﬁcation.

1 {" @c o n t e xt ": " htt p : // w ww . w 3 . or g / ns / o drl . js o n ld "

2 " ui d ": " ht t p : // e x a m ple . co m / p o licy : 0 1 " ,

3 " @ typ e " : " Po l i cy ",

4 " t arge t " : " ht tp : // e x a mple . com / a sse t : mo vie 1 " ,

5 " a s s igne r " : " htt p : // ex a m ple . co m / M ovi e 1 Pa r ty : or g "

6 " p e r m i ssion " : [{

7 " as s i g nee ": " h ttp : // exa m p l e . c om / sma rt - TV /" ,

8 " as s i g nee ": " h ttp : // exa m p l e . c om / smart p h o n e / 0 0

1" ,

9 " ac t ion " : " di s p l ay ",

10 " co n s t r a i nt ": [{

11 " le f t O p e r a n d " : " m e t e r e d T ime ",

12 " op e r a tor ": " it eq " ,

13 " ri g h t O p e r a n d " : {" @ v a lue " : " P 4 H " , " @t y pe

": " xs d : d u r a t ion "},

14 " u n it " : " ht tps : // www . w i k idat a . org / wik i / Q 2

52 3 5 "}]}] ,

15 " p r o h i b i tion ":[{

16 " as s i g nee ": " h ttp : // exa m p l e . c om / sma rt - TV " ,

17 " ac tion " : " di g i t i ze ",

18 " re medy " : [{

19 " ac tion " : " an o n y m i z e "}]}]

20 }

It permits to support a rule being related to multiple

Assets, Parties, and Actions.

ICSOFT 2023 - 18th International Conference on Software Technologies

238

Figure 3: OW ’s main interface along with some functionalities’ outcomes like monitoring.

3.4 Approach Implementation

To put ODRL-W oT TD blend into action, we im-

plemented a system, OW , in Python3 enhanced

with sip, pyqt5, and pyqtwebengine. Additional de-

velopment tools and libraries also include Nodejs,

ThingWeb node WoT, Postman, json, os, Naked,

and pathos. Fig. 3 shows OW ’s main interface

integrating 6 modules: asset deﬁnition that loads

any ODRL editor

, extractor, thing deﬁnition, thing

editor that loads Eclipse Edi{TD}or available at

eclipse.github.io/editdor, deployer, and controller.

We asked asset owners to deﬁne their assets by

enacting the asset-deﬁnition module and then, ﬁll-

ing out the necessary ﬁelds as they see ﬁt. Next and

in compliance with the ﬁrst option of thing identiﬁca-

tion (Section 3.3), we invited an IoT engineer to enact

ﬁrst, the extractor module allowing to generate rules

associated with the already-speciﬁed assets and sec-

ond, the thing-deﬁnition module to generate the initial

WoT TD speciﬁcations of future things like smart TV

(Fig. 4-before). Should the IoT engineer wish to re-

vise these speciﬁcations, he could do so by enacting

the thing-editor module. A video summarizing the

use of OW is available at youtu.be/SCN0EpgWAdE.

To deploy things, the deployer uses a functional

virtual device known as Servient. It provides stan-

dardized access, communication, and control capa-

bilities to physical devices. Fig. 4-after corresponds

to a deployed smart TV acting both as a server offer-

ing services such as switch on and display to users,

and as a client consuming these services. To deploy

assets like movies, we also associated them with a

Servient allowing things like smart TV to use these

assets. To ensure thing compliance with ODRL poli-

E.g., www.w3.org/community/odrl/2019/10/29/odrl-

editors-and-licenses.

cies, the monitor module is enacted as per Fig. 3.

In this ﬁgure, the monitor reports the actions that a

user, through the smart TV, attempted to execute over

movies. Warnings due to rule violations are issued, if

deemed necessary. Finally, the monitor also reports

any updates of ODRL policies like added permissions

or dropped prohibitions.

During the implementation, we had to tackle

many challenges of different complexity levels. For

instance, we had to consider the variety of tools

adopted, the on-the-ﬂy enrichment of assets, the sim-

ulation of real IoT devices and end-users during com-

munication, the alteration of things’ descriptions ac-

cording to ODRL, and, ﬁnally, the real-time monitor-

ing of things’ operations according to ODRL again.

In conjunction with these challenges, lessons learned

include deﬁning assets as things in order to ensure

the privacy of their data and adding on-the-ﬂy new

properties to things like smart TV in order to check

movies’ lists before executing any action. These prop-

erties permitted to communicate to the smart TV what

is permitted versus what is prohibited for each movie.

Although ThingWeb node WoT required accesses to

things’ properties through JavaScript promises, cod-

ing with JavaScript promises was tricky for real-time

applications. JavaScript code-execution is by default

asynchronous, which is not in line with how we envi-

sioned safeguarding the privacy of our things. These

properties played a major role in making things aware

of their current status. For instance, if a request is

sent to smart TV to play movie1, then the play action

will not start until the JavaScript promise containing

movie1’s details is fulﬁlled and the play status prop-

erty contains the value ”Playing”. Consulting prop-

erties’ values happened periodically throughout the

smart TV’s lifetime.

How to Make IoT Sensitive to Privacy? An Approach Based on ODRL and Illustrated With WoT TD

239

Figure 4: Excerpt of smart-TV deﬁnition before/after adjustment.

4 CONCLUSION

This paper presented what we would refer to as a win-

win partnership between ODRL and WoT TD. The

aim is to address privacy concerns in the particular

context of IoT. Users are more and more reluctant to

embracing IoT due to a variety of concerns with fo-

cus on privacy in this paper. To ensure that future

things “know” what they can and cannot do accord-

ing to users’ preferences, captured in ODRL, we ad-

justed these things’ speciﬁcations, exempliﬁed with

WoT TD, according to these preferences that we de-

ﬁne using ODRL-based permission, prohibition, and

obligation rules. A system demonstrating the blend of

ODRL with WoT TD has been developed using differ-

ent tools and technologies, and tested in the context of

a center for elderly people. Real things like smar t TV

and smartphone have been speciﬁed in a way they

have become sensitive to privacy thanks to rules in-

tegrated into ODRL policies. In term of future work,

we would to examine ﬁrst, the appropriateness of ex-

posing things as assets (a cord construct in ODRL) and

hence, could be speciﬁed in ODRL as well, and sec-

ond, the adoption of aspect-oriented programming to

address cross-cutting concerns over things’ speciﬁca-

tions.

REFERENCES

Abdmeziem, M., Tandjaoui, D., and Romdhani, I. (2016).

Architecting the Internet of Things: State of the Art.

In Robots and Sensor Clouds, chapter 3.

Barnaghi, P. and Sheth, A. (2016). On Searching the Inter-

net of Things: Requirements and Challenges. IEEE

Intelligent Systems, 31(6).

Gupta, B. and Quamara, M. (2020). An Overview of In-

ternet of Things (IoT): Architectural Aspects, Chal-

lenges, and Protocols. Concurrency and Computa-

tion: Practice and Experience, 32(21).

Kambayashi, Y. and Ledgard, H. (2004). The Separation

Principle: A Programming Paradigm. IEEE Software,

21(2).

Mohanta, B., Jena, D., Ramasubbareddy, S., Daneshmand,

M., and Gandomi, A. (2021). Addressing Security and

Privacy Issues of IoT Using Blockchain Technology.

IEEE Internet of Things Journal, 8(2).

Qin, Y., Sheng, Q., Falkner, N., Dustdar, S., Wang, H., and

Vasilakos, A. (2016). When Things Matter: A Data-

Centric View of the Internet of Things. Journal of

Network and Computer Applications, 64.

Silva, P., Monteiro, E., and Sim

oes, P. (2021). Privacy in the

Cloud: A Survey of Existing Solutions and Research

Challenges. IEEE Access, 9.

Taivalsaari, A. and Mikkonen, T. (2017). A Roadmap to the

Programmable World: Software Challenges in the IoT

Era. IEEE Software, 34(1).

W3C (2018). ODRL Information Model 2.2. https://www.

w3.org/TR/2018/REC-odrl-model-20180215/.

W3C (2020). Web of Things (WoT) Thing Description.

www.w3.org/TR/wot-thing-description.

ICSOFT 2023 - 18th International Conference on Software Technologies

240