Ingo,
This weather use case sounds promising. It is a classic situation for a
trust framework provider to specify the protocols for a subscription
service to get weather data from all the members (farmers or not).
Standardization of protocols may be obtained through negotiation with
sensor makers or by success of one trust framework which obliges
non-standard devices to conform in order to play (like Facebook).
And from the security standpoint, it may or may not come to be viewed as
"critical infrastructure," depending on how widespread and useful it
becomes. (Other than remote areas that have minimal weather sensors, I am
not sure that the actual solution offers much more value than current
weather data. But this practical consideration doesn't negate the value of
the scenario as a use case.
Jeff
On Mon, Aug 19, 2013 at 10:06 AM,
Hi,****
I’d like to add another use-case. It’s about a service or platform offering end-users to connect all their little sensor for temperature or humidity. With the help of the platform they can connect it with other people or app-provider could build up applications and logic on top of it. ****
Simple example: If you are a farmer just buy one or more sensors (temperature, wind , rain)and connect to the weather platform and you will get access to weather data of all other farmers all over the country. So it’s a kind of crowd weather forcast. ****
*IoT Platform use case*
A company „IDoT Systems“ wants to set up a platform. “South-bound” users can connect all kind of sensors or actuators. “Northbound” users have their apps and solutions to control their sensors and actuators. The platform does access management, policies, persistence, protocol adaptions (if necessary) etc. in fact all classic middleware functions. (see picture below)****
*Possible scenarios are:*
User buys a sensor/actuator and connects it to the “IDoT Systems” platform. With his app he can read and set current data. More advanced applications can combine data from different sensors and control complex processes e.g. in home automation or SME etc.****
A user can also open access to his sensors for other users at the platform or for the internet in general.
**
*Platform pre-conditions/pre-assumptions*
**1.) **Today, devices and sensors speak a lot of different protocols, but most of them are not HTTP. We’ll have many different solution, address schemes and protocols in parallel for a while.****
**2.) **Although we should aim at HTTP RESTful architecture because its flexible, loosely coupled, scalable and lightweight.****
**3.) **Furthermore we can utilize common Web technologies for IdM/Authentication/Autorization.****
**4.) **Elements running with other protocols might be integrated via protocol gateways.****
** **
With a look at this kind platform I see few issues to discuss or for further study:****
**1) **Is it enough for a sensor to implement an OAuth interface?****
**2) **UMA could be the right framework to assign and revoke rights for sensors/actuators?****
Every user could have an own authorization manager.****
With UMA we had also a standardized way to introduce new sensors to the platform.****
**3) **The platform could manage XACML policies ending up in scopes for the actual OAuth request****
****
** **
Best,****
Ingo****
_______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-idot
-- Jeff Stollman stollman.j@gmail.com 1 202.683.8699 Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck
