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

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> 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
> >
>