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

I looked at something similar, and decided that google's approach to the
"physical web", using a bluetooth beacon, was probably a very simple and
quick starting point. Nothing simpler than an android phone acting as a
beacon for test development, broadcasting an URL and a location - there's a
bootstrap point right there.

On Mon, Sep 19, 2016 at 2:34 AM, Timothy Holborn <timothy.holborn@gmail.com>
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> 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
>> >
>>
>