W3C home > Mailing lists > Public > public-credentials@w3.org > September 2016

Re: RWW like Implementations of IoT device management (via WoT)

From: bergi <bergi@axolotlfarm.org>
Date: Mon, 19 Sep 2016 23:59:58 +0200
To: Timothy Holborn <timothy.holborn@gmail.com>, "public-web-of-things@w3.org" <public-web-of-things@w3.org>
Cc: public-rww <public-rww@w3.org>, W3C Credentials Community Group <public-credentials@w3.org>, "public-webid@w3.org" <public-webid@w3.org>
Message-ID: <e2e6ff38-e215-4ebe-f0b5-008ec76009bb@axolotlfarm.org>
Hi Tim,

well, Rome wasn't built in a day. Usually you don't have access to the 
firmware of IoT devices. As you said, current devices are in the range 
from "pay a monthly subscription for the cloud service & app" over 
"there is a HTTP API on your gateway at home" to "the device implements 
protocol xy".

So how do we get from the current situation to "RWW-ready" open 
firmwares and gatways?

1. Implement RWW gateways and generic UI

We can bridge different protocols and also wrap HTTP APIs to clean 
Linked Data APIs. This is mainly a software task, so we are very 
flexible, which is very useful to test concepts. The gateway can also 
host a generic HTML interface.

2. Implement Linux RWW devices

There are already many Linked Data libraries for Linux. The Raspberry Pi 
is already used for some IoT projects. It should be easy to use the 
experience gained from implementing the RWW gateways to make the IoT 
projects "RWW-enabled"

3. Implement Arduino RWW devices

The Raspberry Pi isn't the best option for battery powered projects. The 
Arduino platform is a better choice for this use case. There are already 
many IoT projects, but we need better RWW libraries.

I'm trying to cover 1. and 2. with Dark Horse and 3. with SmallRDF and 
SmallHydra.

But for most use cases there will be a need for a gateway:

1. Caching

If an action of one device depends on the status of another device and 
each device must fetch the WebID profile, an action will take a lot of 
time just to fetch the resources. The number of devices will increase 
and also the rules & dependencies will get bigger.

2. Manage access control

In your AirBnB example, generic rules could be used to grant access to 
all linked devices of the property. These rules would also apply for new 
devices. Also think of the increasing number of devices and how to 
manage them.

3. Bandwidth and power

WiFi consumes to much power for battery powered devices. Alternatives 
like LoRaWAN must be used, but they have very limited bandwidth. Sending 
packets consumes power, therefore traffic should be reduced to the bare 
minimum.

There is already CoAP [1], which can be translated to HTTP, to reduce 
the traffic. But we also need a binary format for triples. EXI could be 
used, but I think RDF/XML is the wrong way. HDT [2] without the header 
and with quad support could be a solution.

bergi

[1] https://en.wikipedia.org/wiki/Constrained_Application_Protocol
[2] http://www.rdfhdt.org/hdt-internals/

On 19.09.2016 03:34, Timothy Holborn wrote:
> Hi Bergi,
>
> I've been meaning to develop an IoT device simply to build the
> firmware.  The view is that RWW Styled implementations enable a retail
> consumer to purchase a product, and that any contract associated to the
> use of that device (save firmware upgrades, akin to life prior to WWW)
> is simply optional / unnecessary.
>
> In my travels, i've obtained a GPS/WiFi/BlueTooth tracking device
> marketed for PETS; alongside a Vehicle Device.  I haven't tested various
> other devices in the marketplace (light globes, etc.) and having worked
> in past with MFG's in ASIA; i understand that if demand is available,
> they'll happily produce devices...
>
> IMHO; most of these devices are plugged into a particular 'app' that is
> required to make the IoT / WoT device work.  Having recently been at a
> conference - the consideration was put forth that perhaps a pace-maker
> may be 'turned off' if the monthly subscription isn't paid!!  Or the
> vehicle will not be able to be turned on, perhaps at a petrol station or
> in a 1 hour parking spot where the vehicle may be towed after a certain
> time...
>
> In some use-cases (ie: domestic violence) i can see use-cases where a
> 3rd party may have access to the telemetry provided by the device for
> law-enforcement purposes (ie: geo-fencing an individual subject to an
> intervention /  restraining order); however these forms of particular
> use-cases are different to having a particular app you must use for your
> IoT / WoT door-lock...
>
> Within the WoT group (apologies if this exists, but i've not understood
> or seen it) do we have a means to advertise functions of a device in a
> manner that allows 3rd party app developers to easily build UX / UI;
> inclusive of 'REC' surrounding methodologies that result in solutions
> that are privacy-preserving?
>
> My working theory was that a 3d barcode could be used on a device to
> share the 'private key', which could be stored on the device owners
> data-space. Perhaps ideally a button could exist to create a new one if
> needed (ie: relationship breakdown, etc.).
>
> Some of this is WoT other parts are outside of scope for W3C?
>
> USECASE:  AirBNB
>
> An AirBNB Host has WoT enabled their property.  an AirBnB API enables
> the Property Host to facilitate billing and property management to the
> tenant for the period of they're stay.  Once the guest/s has gone, the
> Cleaner is able to access the property also. The next tenants arrive,
> and he likes to ensure bread, milk and flowers are on the table.  The
> property host is able to provide directions for where he wants these
> things delivered, and they are able to access the property to do so.
>
> Cameras in the house are triggered for events he feels warrant such
> actions, and a message is sent to the people in the property stating
> this is the case with an approve mechanism prior to property access.
>
> Access is via approved devices (could be a phone, a card, etc.).  AirBnB
> do not produce the apps that enable this function to happen, but rather
> provide an API interface that other developers may build tools to support.
>
> The Property's smart devices communicate with the property owners RWW
> data-space.  He is able to enable messaging with third parties.  He has
> also used the available emergency services credentials as to enable
> quick access to paramedics should one of his tenants require emergency
> medical support, and is unable to open the door upon arrival of any-such
> emergency service persons.
>
> ___________________________________________________________
>
> I haven't reviewed your links yet.  i will do so asap.
>
> Timothy Holborn
> skype: sailing_digital
>
> On Mon, 19 Sep 2016 at 06:29 bergi <bergi@axolotlfarm.org
> <mailto:bergi@axolotlfarm.org>> wrote:
>
>     Hi Tim,
>
>     I think most IoT/WoT standards use encrypted networks and authentication
>     is done by sharing a key to that network or a gateway that does the
>     access control. Encrypted networks can be WiFi or other (proprietary)
>     protocols. Many gateways transfer the data to the cloud. Usually that's
>     not very transparent.
>
>     Because bandwidth and memory can be very limited. The gateway is the
>     best place to implement authentication with decentralized identities.
>
>     Dark Horse [1] will use that approach. It's a Node.js gateway/host using
>     Express. A middleware could handle the authentication. There is already
>     a module [2], but it should be ported to RDFJS spec and Passport [4].
>
>     I'm also trying to shift the protocol and data mapping from the gateway
>     to the device. There is SmallHydra[5] for the ESP8266 and I'm working on
>     a solution for RFMxx [6], maybe with LoRaWAN [7] support. OpenThread [8]
>     would be also an option, but I haven't seen an Arduino implementation.
>
>     bergi
>
>     [1] https://github.com/bergos/dark-horse-server
>     [2] https://github.com/bergos/pubkey-login
>     [3] https://github.com/rdfjs/representation-task-force
>     [4] http://passportjs.org/
>     [5] https://github.com/bergos/smallhydra
>     [6]
>     https://learn.adafruit.com/adafruit-rfm69hcw-and-rfm96-rfm95-rfm98-lora-packet-padio-breakouts/overview
>     [7] https://github.com/matthijskooijman/arduino-lmic
>     [8] https://github.com/openthread/openthread
>
>     Am 15.09.2016 um 10:19 schrieb Timothy Holborn:
>     > I'm wondering what reference material may be available for IoT / WoT
>     > device firmware / platform configurations, where the user is
>     in-control
>     > of the device.
>     >
>     > This in-turn reflects what i'd consider a 'service-centric'
>     approach vs.
>     > a 'human centric' approach.  In the 'human centric' approach, people
>     > would purchase a device - much like they did in the years prior
>     > to/advent of - WWW.  Drivers may be updated to support solving
>     security
>     > flaws or updating to newer standards for communications; but
>     > essentially, the purchase decision does not require any
>     > data-relationship with the vendor of the product.
>     >
>     > I envisage this could in-turn be done via a SoLiD[1] or RWW[2] like
>     > architecture (perhaps inclusive of improvements to existing
>     WebID-TLS[3]
>     > support) with/without credentials[4] use-case support (most likely via
>     > #digitalreceipts #web-payments & server-side interactions?)
>     >
>     > I'm interested in further information, links appreciated.
>     >
>     > Tim.H.
>     >
>     > [1] https://github.com/solid/solid
>     > [2] https://www.w3.org/community/rww/
>     > [3] https://en.wikipedia.org/wiki/Subject_Alternative_Name
>     > [4] https://www.w3.org/community/credentials
>     >
>
Received on Monday, 19 September 2016 22:00:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 19 September 2016 22:00:30 UTC