PlugFest pitch

PlugFest

<kaz> [ OpenDay ends ]

Day2

Plenary

<kaz> mk: check agenda

<kaz> ... and WebEx logistics

<kaz> ACTION: kaz to allocate another WebEx for the breakout session [recorded in http://www.w3.org/2017/02/07-wot-minutes.html#action01]

<trackbot> Created ACTION-100 - Allocate another webex for the breakout session [on Kazuyuki Ashimura - due 2017-02-14].

[Matthias] Scripting API vs REST/network API - API design for HATEOAS

<kaz> mk: (WG Charter Feedback I)

<kaz> ... Scope:

<kaz> ... Make Thing Description the main deliverable

<kaz> ... TD work has priority in the case of conflicts

<kaz> ... RDF dependency:<br/>... don't reinvent a similar framework

<kaz> ... don't make RDF a prerequisite

<kaz> ... Security:

<kaz> ... conduct security reviews before releasing WG doc

<kaz> ... include systematic security testing in the test suite

<kaz> mm: do we hire outside reviewers for security work?

<kaz> mk: one possibility is submitting an internet draft and submit it to IETF

<kaz> ... IRTF T2T has joint meetings as well

<kaz> ... (WG Charter Feedback II)

<kaz> ... why a scripting API for interaction?

<kaz> ... we expect a REST API for Things

<kaz> ... go back to...

<kaz> ... (Scripting API)

<kaz> ... 2 different APIs: scripting API and WoT API

<kaz> ... Scripting API used inside the servient

<kaz> ... simplifies app development for the IoT using patterns from the Web

<kaz> mm: note that Scripting API is an optional feature for Servient

<kaz> mk: WoT API for interoperability

<kaz> ... (REST API)

<kaz> ... given by TD and its interaction model

<kaz> ... client-server, stateless, cache (tricky for legacy protocols; patch through TD?), uniform interface, layered system, code-on-demand

<kaz> ... similar elements: data, components, connectors

<kaz> ... (EVRYTHNG Web Thing Model)

<kaz> ... 4. Web Things Integration Patterns

<kaz> ... 5. Web Things Requirements

<kaz> ... 6. Web Things Model

<kaz> ... how does it compare to the current practices?

<kaz> ... (4. Web Things Integration Patterns)

<kaz> ... direct connectivity: WoT API on Things

<kaz> ... gateway-based connectivity: WoT API on gateway

<kaz> ... (4. Web Things Integration Patterns - contd)

<kaz> ... cloud - gateway - direct

<kaz> (discussion on physical devices and its shadow on cloud)

<kaz> mk: (5.1 Web Things Requirements)

<kaz> ... R0.1: MUST use HTTP

<kaz> ... R0.2: MUST have Entry point URI ("root resource")

<kaz> ... R0.3: MUST support GET, POST, PUT, DELETE

<kaz> ... R0.4: MUST utilize HTTP status codes

<kaz> ... R0.5: MUST support JSON

<kaz> ... R0.6 --R0.1 (MUST support GET on it)

<kaz> ... note the "MUST"s above came from the Member Submission

<kaz> Web Thing Model Member Submission

<kaz> (discussion on requirements for REST)

<kaz> mk: (5.2 Web Things Requirements)

<kaz> ... R1.1: SHOULD use secure protocol ("HTTPS")

<kaz> ... R1.2: SHOULD use WebSockets

<kaz> ... R1.3: SHOULD support [6.] Web Thing Model

<kaz> ...

<kaz> ... (5.3 Web Things Requirements)

<kaz> ... (6. Web Things Model)

<kaz> ... 6.0: Standardized relative URI paths

<kaz> ... 6.1: Common Constructs

<kaz> ... 6.2: Link to related resources

<kaz> ... 6.3: Values

<kaz> ... 6.4: Typed resources (allowed verbs and responses)

<kaz> ... 6.5: Semantic Extensions

<kaz> ... (EVRYTHNG Web Thing Model)

<kaz> ... (WoT Current Practices)

<kaz> ... mostly in line with the Web Thing Model

<kaz> ... evolved to: machine-understandable descriptions, multi-protocol REST support

<kaz> ... hypermedia controls

<kaz> (JSON-LD equivalent format for small devices, e.g., CBOR or EXI)

<kaz> mk: in Montreal there was discussion on level of types

<kaz> henry: looking at how put was described

<kaz> ... within: https://www.w3.org/Submission/2015/SUBM-wot-model-20150824/

<kaz> mk: our uniform interface is a bit higher

<kaz> ... (Hypermedia-driven WoT)

<kaz> ... TD already as hypermedia controls

<kaz> ... links: readable property, see linking breakout

<kaz> ... forms: inputData for actions

<kaz> ... (Start Work on Hypermedia)

<kaz> ... Actions: response to invoke might need to describe interactions on the created running Action, e.g., monitor, update, cancel

<kaz> ... Events: some events such as alarms might need interaction, e.g., confirm, mark resolved

<kaz> ... Errors: error responses should provide interactions to solve the problem, e.g., 401 unauthorized->link to auth server

<kaz> ... (Hypermedia Client)

<kaz> pdf on github

<kaz> mk: project of mine

<kaz> ... high-level browse path description to interaction resource based on link relation types

<kaz> ... programming abstraction based on Futures/Promises

<kaz> ... entry point

<kaz> ... link relation type

<kaz> ... returns Future

<kaz> ... lazy evaluation of Future, not GET

<kaz> (discussion)

<kaz> mk: (Generic Process Relation Types)

<kaz> ... detailed state machine and high-level state machine

<kaz> ... (Handle Change)

<kaz> ... control alternative things

<kaz> ... add new things

<kaz> ... still control old things

<kaz> ... also control future things

<kaz> ... (Idea)

<kaz> ... diagram of ideas

<kaz> ... programming abstractions?

<kaz> jh: comment on hypermedia client

<kaz> mk: we can extend the model based on this hypermedia model

<kaz> henry: think it's something actually working for WoT

<kaz> ... building a hyper media client

<kaz> mk: think about use cases like this

<kaz> ... would like to create a TF

<kaz> ... also work for error model

<kaz> ... report errors and recover from them

<kaz> ... overlaps between those two topics

<kaz> dsr: overlap with semantic work as well

<kaz> mk: next Sebastian?

A thing description can be considered as an RDF graph with links to other such graphs. So for an RDF API you have a means to follow such links to access the linked graphs

[Sebastian] TD model (discussion of the TD model independent of serialization format)

<kaz> sk: would like to go a bit backward

<kaz> ... to make clearer understanding

<kaz> ... (WoT TD Basic Assumption)

<kaz> ... Servient1 using JS and Servient2 using C/C++

<kaz> ... S1 provides information and S2 consumes it

<kaz> ... S2 understands what S1 provides

<kaz> ... what is the core information of the TD?

<kaz> ... TD should be independent of any platforms and programming languages

<kaz> ... reflect the core data model

<kaz> ... (JSON-LD vs TD Model)

<kaz> ... promising candidate for TD serialization

<kaz> ... quite human readable, good experience in plugfests

<kaz> ... (Inputs for the TD Information Model)

<kaz> ... (Tool?)

<kaz> ... what kind of graphic tools?

<kaz> dsr: have some idea

<kaz> sk: (TD (core) Model)

<kaz> ... Thing has name

<kaz> (discussion on "name")

<kaz> sk: (starts to draw a diagram on the whiteboard)

<kaz> <img alt="Sebastian's diagram" />

<kaz> mk: would suggest we clarify the basic pieces needed for implementations

<kaz> ... and then we can agree on the terms

<kaz> ... recommending bottom-up approach

<kaz> mm: building a model based on use cases

<kaz> mk: we can optimize the model but don't have to use the whole RDF mechanism

<kaz> mk: would like to summarize the discussion

<kaz> ... we go based on implementations using bottom-up approach

<kaz> ... the most important point is how many boxes are needed here (=within the TD Model)

<kaz> mm: we should write down requirements

<kaz> dsr: we should look at existing specs generated by other SDOs, e.g., OCF

<kaz> mk: we can see their implementations via liaison

<kaz> mm: grounded with the PlugFest results is important

<kaz> ... prototyping using RDF

<kaz> mk: we have the Current Practices as the starting point

<kaz> ... (draws a diagram of discussion cycle on the whiteboard)

<kaz> <img alt="Matthias' diagram" />

<kaz> mk: RDF prototyype => Serialization => Implementation => ER Model => RDF again

<kaz> mm: like that

<kaz> dsr: in addition, other SDOs' IoT platforms as well

<kaz> greg: mentions importance of test suites

<kaz> mk: (adds "Existing platform")

<kaz> mm: wonders how to handle, e.g., OCF test suite

<kaz> kaz: would it make sense to invite OCF guys and/or oneM2M guys to PlugFest?

<kaz> sk: already trying, though...

<kaz> mk: why don't we have a morning break now and calm down :)

<kaz> [ morning break ]

<scribe> scribenick: dsr

Type system

Matthias introduces the session and talks about JSON Schema

A discussion around the type system and which one should we choose.

Can we use an existing one or do we need to define our own?

Greg: in any case you should ground this in RDF.

<kaz> Type System discussion on GitHub

Matthias displays a table that has rows for different kinds of types and columns for different type systems, e.g. JSON schema, Schema.org, and so forth

JSON schema can be mixed into other frameworks, e.g. RAML

Specs for JSON Schema have been geared around having a media type

Matthias: the aim is to have a machine interpretable format, so that a servient can understand the data model types.

<kaz> 3.2.4 Type System from the Best Practices document

Interactions can be considered as web forms that guide how to interact with a remote server

Hyperschema covers both client requests and server responses.

Some discussion around REST APIs in relation to what is needed in the request and response.

Matthias: the thing description enables a client to know how to interpret the server's response.

In the WoT IG current practices, we have used JSON Schema to describe the structure of the data in the requests/responses.

Greg: one of the reasons for using URIs for naming is to allow you to dereference them to get further information.

Time for thinking about how to evolve JSON schema to better support the increased level of interest in Linked Data and JSON-LD

Matthias: the recent discussion around iot.schema.org sounds promising.

Its great to have people from the different groups here today, and it would be great to continue this remotely (some discussion about number and timeslots for telecons)

Matthias: we need to be careful to avoid tying the data models to the serialization formats

Sebastian shows a slide where JSON Schema is used to link to an external model (modelReference)

Some issues around use of "properties" and potential role of scoped contexts in JSON-LD as a work around

<kaz> BIG IoT EU Project

Sebastian shows an example from the EU project BigIoT which he is a part of

MichaelK: I've seen "describedBy" rather than "modelReference".

Greg talks about having a document being both JSON-LD and JSON-Schema

Both specs need a namespace for their core concepts. In JSON-LD is is common to alias terms beginning with $, except for @context where must use the term as is.

The $id in JSON schema does provoke a lot of discussion as it can be a little confusing

There is a means to set the base URI when combining several schema into one document.

MichaelMc: We can used JSON-LD's scoped context to only apply some aliases within the scope of a valueType object.

Greg and Henry agree to further discussions on avoiding conflicting identifiers in JSON-LD and JSON Schema.

JSON Schema exists to describe the structure of a document, whereas JSON-LD exists to express Linked Data in JSON.

They therefore serve different purposes and are complementary.

Greg: it would be interesting to use JSON-LD to embed annotations into a JSON Schema description of a JSON document.

Matthias: for thing descriptions we have requirements where both JSON-LD and JSON Schema are relevant.
... we will have the security break out at 13:30 PST

<kaz> [ lunch ]

Security for the Web of things

Zoltan introduces the session, starting with a review of security in OCF.

A platform can host multiple devices, and a device can host multiple resources.

Security is needed for connectivity, discovery, access control and device management.

Each device as a globally unique UUID that is validated by OCF

Access control is granted on the level of the device resources

The access control information is held in secure storage.

All requests are passed through the OIC resource manager.

Security bootstrapping is complex: on-boarding, provisioning and configuration are defined by OCF.

Configuring resources and provisioning cloud services are application specific.

OCF hasn't discussed how to provision cloud based services.

OCF devices may act as clients and/or servers.

Access control lists are held in the server or in an external resource.

OCF on-boarding involves a transfer of ownership, which entails anonymous key exchange using the Diffie-Hellman algorithm.

Alternatively, you can use a clean room transfer (to avoid man in the middle attacks)

Or you could use a second channel, e.g. NFC or Bluetooth

Provisioning deals with certificate exchange.

This is followed by a configuration step.

Message integrity is based upon DTLS over CoAP, along with JSON Web Encryption + Web Signatures.

What are the prerequisites for the Web of things in respect to security?

Is on-boarding and provisioning in scope for the web of things, or are these something specific to the given IoT platform?

Zoltan: I've described OCF's approach to security as relevant background knowledge, but we need to discuss the requirements more broadly for the web of things

Do we go by the web browser security model along with an origin URI?

I don't think so, as it doesn't scale well.

Black listing is poor practice. White listing is better.

Zoltan: Ownership transfer is best done with manufacturer's certificates.

Matthias: we need authorization in addition to authentication

Dave: last year we were discussing organising a joint white paper on security with individual contributions from people from a broad range of organisations.

Zoltan: perhaps we just need to establish a secure tunnel and defer security to the platform.
... I have no opinion in respect to the joint white paper

MichaelMc: One suggestion is to involve the IETF to help drive a dialogue on security.

Matthias: We could write an Internet Draft on a particular scenario and use that for discussions within the IETF, and to focus on how to use the mechanisms that the IETF groups have developed.

Michael: the WoT WG charter makes a number of requirements on the work we are expected to do, including strong security review.

Matthias: different platforms use different security building blocks.

If a device hasn't been onboarded then we wouldn't have a means to talk to it.

Discovery is dependent on the kind of network things are hosted on.

Johannes: the IG discovery task force came up with a handful of categories of techniques for discovery.

In principle, thing descriptions could include certificates signed by device manufacturers.

The biggest problem is that we now need to attract security experts for the task force.

scribe: end of session ...

This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/WG/(WG/
Succeeded: s/1/1)/
Succeeded: s|dependency:|dependency:<br/>... |
Succeeded: s/Feedback 1/Feedback I/
Succeeded: s/Scripting/note that Scripting/
Succeeded: s/mk:/mm:/
Succeeded: s/mm: one/mk: one/
Succeeded: s/$/R/
Succeeded: s/sk: need some more time; maybe some time tomorrow?//
Succeeded: s/vocabulary/terms/
Succeeded: s|https:|-> https:|
Succeeded: s/that has/that has rows for/
Succeeded: s|type-system|type-system Type System discussion on GitHub|
Succeeded: s/thanks//
Succeeded: s/descriptio/description/
Found ScribeNick: dsr
Inferring Scribes: dsr
Present: Carlos Daniel Darko Victor
Agenda: https://www.w3.org/WoT/IG/wiki/F2F_meeting,_February_2017,_USA,_Santa_Clara#Tue.2C_07_Feb_2017:_PlugFest_.2F_Technical_Breakouts

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 07 Feb 2017
Guessing minutes URL: http://www.w3.org/2017/02/07-wot-minutes.html
People with action items: kaz

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.