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

It looked to me like the Eddystone method relies upon the Google cloud?

https://developers.google.com/beacons/eddystone#setting_up_a_beacon_with_eddystone

The RWW method sought to provide independence as an alternatives?

I note various linked-data-notifications related works,

But is what you're saying mean I'm misunderstanding the Google offer? I
hadn't confidently found a solution that was independeny, which I blamed on
the lack of a RWW like solution to plug it into...

The owner of the device would need a standards based place to store the
data / telemetry, et.al. then, I envisage, support ontology orientated
accessible factors...

Re: bootstrapping, agreed.  Perhaps simpler than doing something similar by
loading-up Ubuntu and solid-node-server, to test an alternative POC... ;)

I was planning to get a raspberry PI, adding some solid-state relays and
sensors...

Tim.H.

On Tue., 20 Sep. 2016, 3:18 am Nathan Rixham, <nathan@webr3.org> wrote:

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