## Title: SIFIS-Home hazard labels

### Submitter(s):

Luca Barbato

### Reviewer(s):

<Suggest reviewers>

### Tracker Issue ID:

<please leave blank>

### Category:

"vertical"

### Class:

<please leave blank>

### Status:

<please leave blank>

### Target Users

- device owners
- device user
- device manufacturer
- gateway manufacturer

### Motivation:

Connected devices have an impact on the physical world more than often interacting with them may have unintended consequences.

The [SIFIS-Home](https://sifis-home.eu) project tries to prove it is possible to have the connected device deliver the information regarding which are the potential hazards involved in every interaction with increasing granularity and mechanisms to detect or prevent them from happening.

### Expected Devices:

Any device that may pose a physical or privacy hazard to the user e.g.:
- Fire hazards: Ovens, Stoves, Lamps
- Flood hazards: Windows, Faucets
- Invasion: Doors, Windows
- Privacy: Cameras, Microphones

And so on.

### Expected Data:

The devices should provide some kind of labeling metadata to deliver the hazard information connected to interacting to it.

It could be as coarse as cover any interaction on the device or specific to the point of specific range of operation (including interactions).

### Dependencies - Affected WoT deliverables and/or work items:

The current Thing Description is adeguate to support the model.

The labeling information can be bound to the specific Form Operation for each Interaction Affordance (Action and Property).

To support the finer level of granularity a system to extract information from the input data and the relation between multiple properties would be needed.

### Description:

The user may have a mean of setting policies to restrict interactions with connected devices: e.g. Stop any interaction with the Oven if it not a cooking time, require stronger authentication to open a door if the user is considered already inside the house.

The home system may automously change the state of a device to reduce the risk level, e.g. reduce the brightness of an Halogen Lamp or start the A/C system if a room temperature is outside the bearable range and a person is detected inside.

### Security Considerations:

The system relies on being able to trust the information exchanged and has to detect bad actors.

### Privacy Considerations:

Privacy is one of the hazards that may be accounted for, it is no different from a physical hazard in this model.

### Accessibility Considerations:

The system may be extended to cover accessibility concerns and have specific policies.

### Internationalisation (i18n) Considerations:

The hazard label information should be translated.

### Requirements:

The Thing Description does not have specific fields to deliver the information, the Form has to be extended and the Thing itself has to accomodate a field to hold the information required to express potential hazards with the finer granularity.

#### Protocol Requirements

"flexible"

#### Content Type Requirements

"flexible"

#### Platform or Standard Requirements

"none"

#### Authentication and Authorization Mechanisms Requirements

"flexible"

### Gaps:

### Existing standards:

### Comments: