---
tags: Dias
---

# Logger

The client is an SDK that creates hash or signature chains. Chains are uniquely identified by source + type. Source is given by a DID. The SDK keeps track of the necessary context (e.g. previous hash per chain/type). The SDK itself does not care about persisting the data points or transferring them to the cloud. This should be the job of client where the SDK is used/embedded. Transport could be done via HTTP(S) or MQTT.

The general idea is inspired by
https://developer.ubirch.com/utp.html
https://github.com/ubirch/ubirch-protocol

## System Requirements

- We need a confirmation/receipt from the log server in or

## API

### Initialize SDK

Init with DID

### Create chain

accepts type

### Add value to chain

optional if value should be signed. Default is true

## Dataformat

{
    source: <did>
    timestamp: <UNIX timestamp>
    type: <type>
    value: <value>
    prevHash: <Hash of prev element>
    proof: <JSON Web Signature (JWS) value or empty> 
}

Start with [did:key](https://w3c-ccg.github.io/did-method-key/)

### Questions
- Should source + type identify the chain? YES
- Should source be a DID or DID URL specifing the key?
- Should proof property be included in hash?
- Is JSON + JWS the way to go or should we use JSON-LD or more efficient structures such as MessagePack, CBOR or Protocol Buffers?

### Examples with Kuksa

#### Malfunction Indicator Light (MIL)

  type: "Vehicle.OBD.Status.MIL"
  value: Malfunction Indicator Light (MIL) False = Off, True = On >

#### Diagnostic Trouble Codes (DTC)

  type: "Vehicle.OBD.Status.DTCList"
  value: <List of currently active DTCs formatted according OBD II (SAE-J2012DA_201812) standard ([P|C|B|U]XXXXX )>

Source: https://github.com/GENIVI/vehicle_signal_specification/blob/master/spec/OBD/OBD.vspec

### Working with Encrypted Data

`type` and `value` fields can be encrypted.
Each stream uses an unique symmetric key. The symmetric key can be encrypted with recipient keys to enable sharing with predefined parties

# Verification & Validation SDK

This is an additional software component which will not run on the vehicle.

## Verification

Describes the cryptographic verification of the chain

## Validation

Adds business level validation logic.
Examples:
- Odometer value should increase monotonic
- NOx value should be within specific bounds
- Malfuncion Indicator Light sould not be cleared too often within a specific timeframe