Web of Things F2F, TPAC 2019 -- 20 Sep 2019

<dsr> scribenick: dsr

Logistics and Agenda discussion

Michael does some agenda bashing including ideas for future F2F locations.

Use cases and requirements

McCool: The TAG were looking for the WG’s use cases and requirements work, this doesn’t existing in a formal way at present. We should rectify that.

Shows the next steps slide for the Munich WoT workshop

This has 3 columns: update, next and new

The WG Charter proposal relates to the Workshop results

One change is that following input from the Decentralised Identifier WG, McCool has renamed the corresponding work item from Identity to Identifier management.

McCool: any other ideas for the charter?

sebastian: we heard some comments about our approach to eventing …

<kaz> McCool's slides

sebastian: some thoughts about testing in respect to eventing

McCool: do we do testing or just interoperability

We have some testing gaps, including eventing

scribe: some discussion about testing tools

Kaz: 2 points. first, how we report the output of the plugfests
... yesterday’s voice assistant breakout touched upon relation to WoT

McCool: we don’t yet have a work item on accessibility

<kaz> s/yesterday's/2nd, yesterday's/

dsr: this is an opportunity to bring in some accessibility experts into the WG

Ideathon

Slides on possible use cases for 2nd generation of WoT standard

Presented by NRI

(slides to be archived later)

Japanese Web community have been thinking about ideas for future WoT standards

(NRI = Nomura Research Institute)

<kaz> @@@slides tbd

An “Ideathon” took place on 23-24 August 2019 with 22 participants

Slides full of detailed content (very small print)

One example is a “Poop checker”

This is a medical diagnosis application

and comes with a list of potential devices, e.g. toilet with sensors, smart speaker etc.

and some requirements related to the WoT WG charter

Michael: that reminds me that we have yet to address orchestration across multiple devices

2nd use case involving a camping car

(mobile home)

3rd use case is a security robot, e.g. to inform people when someone is breaking into their home

This is an autonomous vehicle …

the use case also includes wearable devices

3rd use case is a security robot, e.g. to inform people when someone is breaking into their home

This use case has requirements in respect to: link relation types, interoperability profile, complex interactions, discovery, privacy and security

Dave: I am involved in a new European research project (GATEKEEPER) on applying WoT to healthcare, including early diagnosis of medical conditions

McCool: we are especially interested in new requirements

some discussion on linking types

McCool: is there a way to ask the workshop participants in case we have questions?

Answer: yes

(via email)

McCool: I will shortly talk about a template for use case descriptions for our work item on use cases and requirements

In the context of these slides - what columns we expect

The slides have idea (title), overview (short description), devices involved and data (what data is involved)

sebastian: I like this general approach, but also like preconditions, the goal to be reached and the expected outcome for each use case

Are we describing a problem only or a problem and a solution to that problem

slides providing a summary of the ideathon

(text too small to see from back of room)

One challenge is who will pay for sensors in public spaces

The method of trading data, …

An issue of how we can set up databases

Role of local government and secure management of data

Any questions? [no]

[round of applause in thanks for the NRI input]

Michael shows slides on use cases and requirements

<kaz> @@@slides tbd

The TAG asked us to prepare more formal use cases and requirements. Alan Bird further suggested we should note the business justification for use cases.

We also need to ensure that the use cases have the consensus of the WG

We further need to do this before starting significant work

Where work has already started, we need to go back and document the use cases that justify the work

Michael proposes some ideas for templates for use cases

The suggestion that we start with a concise user story - as a type of user, I want to achieve some goal so that some thing is realised

e.g. as a developer I want ease of use so that I can develop WoT apps faster

We need to define categories of users

We should classify the use cases into those that are accepted, those that are proposed and awaiting a decision, and those that are rejected

We can start by brain storming some some possible requirements

and then decide which ones are crucial

We should try to define the problem but not the technical solution

dezell: rejected is a little harsh as a term, use cases should be archived even if not deemed important

Michael: some use cases could be out of scope

Similar approach is needed for the WG’s design decisions

We need a clear process and record of decisions

Which decisions were accepted and which were rejected

sebastian: what kind of use cases would we want?

Michael: my view is that use cases should be user oriented, e.g. as a businessman, I want to …

Dave: we should emphasise use cases that motivate companies to adopt and exploit the web of things

<kaz> mmi use cases

Michael: the issue tracker tends to be a little free form, and we need to extract and formalise our descriptions of use cases, requirements and design decisions

<kaz> kaz: agree it would be nicer to have a compiled document (and provides an example above)

Michael slows his ideas for how we could apply this to WoT profiles as an example of a template structure

[link?]

<kaz> Michael's initial proposal

Michael talks us through the proposed structure

Michael: for example as a home user, I want to know that a given device will work in my home environment

The next step is to turn this into an actual template

Kaz: we could start with this and use github issues for managing use cases, but we need to generate a compiled use cases document in the end.

Any comments on this template? [no]

sebastian: what is the timeline for this work?

Michael: I think by March, we should have this in a good shape

Dave: do you expect to have both use cases and requirements and design decisions by March?

Michael: there’s actually four things …

Dave: another point is how we can relate this to our horizontal review plan

Michael: we need to get such review early and often

Dave: we need to ask for review when we have work in a good enough state for reviewers to justify their time

<kaz> MMI use case document as another example

Michael shows the MMI WG’s WG Note for their use cases

The motivation has some questions in italics from a template

Michael: the use case needs to clarify the time sequencing in the story

dezell: how do you differentiate a use case from a user story?

Michael: a use case is more formal

dezell: I am happy whichever way you go, but please be consistent

<dape> http://w3c.github.io/wot/ucr-doc/

Dave: we could talk to the TAG, and ask in the chairs list for comments and input on the process and templates for use cases

Michael: we should allocate further time for this in future calls

Kaz: do we want to set up a task force to guide this?

Michael: let’s discuss that in the next call as we’re out of time now

<kaz> [break till 10:45]

<dezell> scribenick: dezell

WoT Testing Framework

presenter: Ege Korkan, Siemens AG

ege: working move the playground to the JSON-LD model

See: https://github.com/thingweb/thingweb-playground

<kaz> @@@ slides tbd

(Note: presentation will be linked from the agenda.

ege: new features - live validation, saving TD as a gist online, filling the editor with an example TD
...: a gist must always be valid.

kaz: do you mean all the TD submission would be automatically validated every time using some plugin (like pr-preview)?

daniel: there is some confusion on this point, it's more of the capability to share.

McCool: we also need to "feed" some repository.

ege: the idea is to make creating a new TD simple and quick.

McCool: a selection of templates might be a good idea.

ege: more new features - optional assertion testing on front-end, importing a TD, better error messages.

McCool: error could link back to TD to explain what failed.

ege: (demo of the page for Thing Description Playground)

<dape> http://plugfest.thingweb.io/playground/
...: there is the ability to enter an example invalid TD to check operations.

McCool: we need to see all the errors, not just the most recent.

ege: the tool will automatically validate the TD, with line/column.
...: "gistify" allows you to name and save the contents. But you must be logged in to save.

<dape> https://gist.github.com/
...: so you can save these TDs without resorting to external storage.

McCool: It would be great to have this automatic checking available for people to use with their own repos (on checkin).
...: "integrated tooling for git."

ege: question - do we want to make the set of "gists" somehow official?

McCool: we should talk about whether we want TD integrated into regular W3C git repositories.

dsr: there's a lot of complexity about using W3C logos or making broad claims about compatibility.
...: reports of compliance are always based on trust (today).

McCool: but it would be helpful to know that trust is backed up with tests.

sebastian: can you query all tests related to a TD (gist).

s/)\./)\?/

ege: you can explore your gists, but there's no direct query - github doesn't know a gist from other things that you put in there.
...: we could improve things by allowing >only< gists.
... future work - should we have ... 1) script based validation as an npm package, 2) a server to send TDs and get validation results.

McCool: a separate server would be helpful for those who don't want to install Node.

ege: behavior testing:
...: - tool to fuzz test all interactions of the TD
... - test bench is being updated to generate .csv
... Also ability to test external things against TD (e.g., messages are schema valid)

McCool: this discussion raises the issue "are properties static"?

ege: deployment options - need opinions:
...: - as an online server, allows only online exposed things
... - installing locally (own machine, installation overhead)
... - testing from own browser (limited to HTTP)

McCool: seems there are two cases - testing real devices and testing simulated devices.
...: need to do both.
... "browser" option is a convenience for getting started.

daniel: first and third are the same in terms of the UI, whereas the second is potentially different.

ege: consumer testing (consumes messages)
...: clinet-data-schema, client-data-schema-accept-extras, client-data-schema-no-extras, client-uri-template
... given a TD, npm can create a Virtual Thing: can generate a report, or be hosted online on Thingweb.
... important to identify TDs that cover many features, making sure of a thorough client test.

McCool: would like to use virtual things for testing, but also monitor traffic between a real thing and real client and diagnose the health.

ege: behavior testing: break them
...: - safety testing (invalid inputs to Exposed Thing, returning invalid data to consumers)
... - security testing (pen-testing based on security information, invalid security information on ETs)

McCool: any questions?

Answer [no].

<taki> scribe: TK

<taki> scribenick: taki

Marketing

Sebastian: wants to discuss WoT Web Presence.
... first set of deliverables are ready soon.
... I met lots of poeple who are interested.
... It is difficult to provide something for them to read and learn, such as introduction.
... I am contributing to other consortia. OPC-UA, eClass, etc.
... easiest way is first to fix our web page.
... we have plenty of web pages now on W3C site.
... Not very helpful for newcomes.
... they do not care IG/WG etc.

McCool: the WoT landing page as the entry point is important.
... other pages can be elsewhere.

Eric: WoT is messed up, complicated multiple IoT/
... people not engineer want to deploy smart city, etc.
... will hire consultant.
... They look at W3C WoT side. it does not resonate now.
... business people control budget.
... cannot only cater engineer.
... have to communicate to business people who control budget.
... need to think abuot customer base.
... slide show / video show that describes problem statement (e.g. smart city). Up-level it, script it so that business people can understand.

McCool: up-level does not necessarily mean abstract. still needs to be concrete.
... we need concrete examples.

Eric: up-level means speaking to architect.

Sebastian: Next question. where are pain points now?
... three different web pages.
... newcomers think what are the relationship?

McCool: entry point should describe that.

Daniel: the pages should look the same.

McCool: they can search and get to sub-page.
... we can re-design UI

Daniel: home button etc. UI needs to be consistent.

McCool: normalization.
... and there is structure issue.
... navigation issue is one.
... we need volunteers.
... to fix navigation problem immediately.

Daniel: three different pages now.

McCool: longer term, we need to clean up.

Dave: there are short-time and long-time issues.

Daniel: current status, goals and how to get there. we need to think about this.

Sebastian: we are staring a new charter. need to think about branding.

Eric: How do you explain DID to laymen.
... I have my own "close line".
... to explain complex thing to laymen.
... I can help in this effort.

David: domains are important.

Dave: top-level entry page is up to us.

David: It used to be cleverer before.

McCool: what resource does W3C have for help?

Dave: very little.
... use cases is more important than navigation issue.

McCool: Do we want to create marketing TF?

Sebastian: We used to have marketing TF before.

McCool: It is a short-time focused project.
... Dave and Kaz can initially help on landing page issue.

Daniel: we tried before, but there were lots of restrictions by W3C.

Dave: I can help on getting permission.
... W3C has flat structure.
... each group has independence.
... we first need to think about function.
... then think about what do we want to say.

McCool: let's separate short-term and long-term tasks.
... Landing page content is long-term.
... there are also medium term tasks such as launching landing pages.

Kaz: we need to think about concrete use cases and requirements about this.

<kaz> html wg page

Kaz: HTML WG has automatically generated page, for example. I am not proposing anything.
... possibly our WG pae and IG page can be automatically generated like that..

Daniel: we should reduce complexity.
... from business people's perspective.

Kaz: I am not suggeting anything.
... My point is that we need to clarify issues and requirements, i.e., what kind of information should be included in which page.

McCool: we can incrementally change instead of radical big change.

Dave: we need to regularly invest time.

McCool: let's think about action items.
... marketing TF sill the end of year.
... we need a repo.
... we need to discuss in main call.
... somebody needs to make strawman proposal.
... we need to define concrete action items.

Dave: we need to invest time.

<kaz> s/I am not suggesting anything./please note that I'm not suggesting we should use this automatic generation mechanism for WoT. This is just one of the possible options/

McCool: I am also going to join the marketing TF.

Sebastian: at least fix the short-time tasks by the next F2F.

McCool: obviously wrong things.
... eg. delete ancient content.

Dave: procedure?

McCool: Sebastian to create strawman.

Ege: twitter account can be considered.

McCool: it is a long term task.
... let's create a wikipage for marketing TF.

Kaz: and GitHub right?

McCool: yes and doodle poll.
... task list should be discussed using email.
... 2 weeks from now we have a main call and have strawman discussed.

<kaz> [lunch till 1pm; room locked till 12:50]

<kaz> scribenick: kaz

Joint Meeting with JSON-LD WG

sk: we had good discussion during TPAC 2018
... helpful to clarify issues
... would talk about the current status and issues closed
... unfortunately, Victor is not here
... he takes care of the mapping, etc.

@@@slides tbd

sk: 2 topics here
... container object for TD security definition
... and
... note on the difference between a JSON-LD context and an RDF vocab

ih: magic source :)

sk: what are the LD features, etc.

mm: one more thing about JSON vs JSON-LD
... maybe would add a new feature?

sk: wot architecture issue?

mm: right
... nice to consider that issue as well

ih: for the last one, we'll have a session about that
... at 2pm during the JSON-LD meeting

ms: how to address who wants to use JSON vs JSON-LD?
... if we have time, let's chat about that

sk: let's start with the first issue
... [Container Objects]
... use case: a WoT developer writes a TD for a "Thing" ...
... [Container Objects (example TD)]
... left side: the current TD
... right side: no container
... (enlarge the example TD)
... security scheme is mandatory
... then you can assign some interactions here
... which scheme to be applied
... basic, basic and psk
... on the right hand
... equivalent TD with no container
... unexpected repetition of "basic" here and there
... w3c/json-ld-syntax

<sebastian> https://github.com/w3c/json-ld-syntax issue 19/issues/19

sk: Indexing without a predicate

<azaroth> The resolution for api#19 resulted in this section of the current spec: https://www.w3.org/TR/json-ld11/#included-nodes

sk: (shows the example data)
... maybe you can comment on this

azaroth: issue 19 resolution above
... (shows 4.7 Included Nodes)
... there are 2 nodes
... minor change here
... id was a key for match
... (enum#c6 and enum#s2)
... classification for the same URI
... this could be a solution for your issue
... here is the definition (Example 104)

gk: inline or embed

mm: question is normalization
... normalized version may be clean

sk: update context by included nodes
... sounds good

gk: note that not included in the context any more

azaroth: options to offer inline or embed

sk: sounds very good
... next
... Context vs Vocabulary
... how to make this clearer?
... many people have a look at context
... class definition here
... but based on RDF

azaroth: one of the non-REC track document about primer
... nice to describe this point
... we expect to work on a primer
... explain JSON-LD to more developers

gk: in JSON-LD 1.0, we didn't really talked about the issue
... similar to other RDF notation

ack ...

<Zakim> ..., you wanted to comment on the right

sk: there is discussion on automotive vocabulary
... could be reused for WoT purposes

ms: here is a real problem
... we need to think about a tool so that people don't need to understand the detail of RDF

mm: good idea to have a simple framework for that
... naive people don't care RDF at all

azaroth: confusion about what "mapping" means
... RDF class to resource
... only for mapping existing terms
... not creating new data

ih: you define constraint
... it's a super version of abbreviation
... not only listing but describing

mm: maybe related to another issue on validation too

ssstolk: there is a construction infrastructure
... help create semantic definitions
... magic terms as linked data
... want to share
... need to consider what is relevant to users

bigbluehat: not going to the context but another resource

mm: good example is security vocabulary
... now we're using JSON Schema
... problem with additional features
... how to validate the extensions

ih: another WG working on JSON-LD vocabulary
... we can normatively refer it
... SHACL is probably a machine gun
... become complicated
... it depends what you need
... JSON Schema may be alright

ms: in VCWG, we have the same issue
... variety of different languages
... we can say this object conforms to this schema
... whatever schema to be included
... that said
... very strong preference for JSON Schema
... a lot of APIs would take data in the auth of wire
... most implementations force you to give JSON in a certain form
... use of JSON Schema help us enforce semantics

bigbluehat: you can still validate before processing context

sk: another question on JSON vs JSON-LD?

mm: yes, that's our priority

sk: shows issue 371
... TAG interoperability concerns
... do you have the same problem?

bigbluehat: you can use any names for your local vocabulary

mm: original point is JSON within JSON-LD

<Zakim> manu-wot, you wanted to discuss no jsonld processing

rob: wanted to say "don't do that"

gk: core usage of JSON-LD is you take the data

mm: the spec doesn't allow to rename things

by: if there is another community working on different vocabulary

<Zakim> azaroth, you wanted to talk about gateways

by: the question is when do you want to check it (before/after the conversion)

gk: reframe the data

rob: data passes transformations
... a very easy gateway
... to convert input context to output context
... not interoperability concern but implementation concern

<dape> +q

sk: we're responsible how it should be done

kaz: do we want to explain that to David?

mm: make response on GH?

ih: btw, 2 more weeks for JSON-LD CR :)

gk: at least by the end of October

ms: the WG basically ended up that JSON-LD is the normative stuff
... that's the right answer
... we say in our spec you must add @context and everybody has to process it
... WoT context should be located at the top
... you can specify another file

<azaroth> Timeline for CR has the following switches: 2 weeks to process existing editorial issues (mostly typos) ; + 2 weeks if we need to deal with text direction ; + 2 weeks if we need to revise the version announcement

ms: overlay comes second

sk: do you have an example?

ms: Verifiable Credentials Data Model

Verifiable Credentials Data Model

ih: if people want to use the basic capability don't need to use JSON-LD

<dape> scribe: dape

Discovery

MCC: Presentation is checked in already

<inserted> Web Annotation Data Model as another example

<McCool> https://github.com/w3c/wot/blob/master/PRESENTATIONS/2019-09_WoT-Discovery.pdf

MCC: "Disovery" part of charter
... Requirements
... distribution mechanism of TDs

<mlagally> Good afternoon - can you hear our audio?

<mlagally> Yes, it works one way. Zoltan and I can also hear each other

MCC: Capabilities: local/global discovery, semantic queries, directories, peer-to-peer
... Privacy-Preserve Architecture: Device & Information Lifecyle, authorized users

<mlagally> @kaz: seems not to work

<mlagally> now with echo

<mlagally> echo got crazy

<mlagally> n oaudio at all

<mlagally> no audio at all

MCC: Alignment with existing standards
... get others on board, e.g., IETF core resource directories
... core link format

<kaz> remote+ Elena, Lagally, Zoltan

MCC: Singapur meeting is a change to get in contact
... Optional: support for scripting API
... Proposal: Two Phase Discovery
... find out adress to next step
... address has no information per se
... afterwards, I authenticate service
... with authorization I can do queries et cetera
... simple queries vs full semantic power
... directory can run in cloud, gateway, ...
... registration might need to be refrehsed

<Zakim> manu-wot, you wanted to note always support no jsonld processing.

MCC: well-known/td could be used as a "known" entry point

DSR: how can I advertise a service that can be tight to a device?

MCC: discussion with Zoltan about management API

DSR: we need to look at this broader aspect.. incubation is good with that regard

MCC: I do think this is not prevented

<taki> +q

<kaz> MMI registration&discovery UCR Note

<inserted> kaz: Agree, we should generate use-cases/requirements document for discovery topic as well. an example document above.

<dsr> There will be a market for applications for managing and exploiting devices, and the need for integrating this with the discovery model described by McCool

ML: where are these requirements coming from?

MCC: first draft I came up with
... need to work on strawpan ... till we have solid set

ZK: 2-phase discovery: same rules apply for any other service

MCC: useful to define TD for discovery/directory

<dsr> Devices could register with a directory in the cloud, enabling users to determine which applications are compatible with their devices. This can be done in ways that protect the user’s privacy

ZK: pressure on OCF to realize certain discovery service?
... client API in scripting provides way to identify the type: local, directroy etc...
... authentication part of wot runtime

MCC: It is ok to have diversity
... directory should be strict about authentication
... will write up requirements document to discuss

Matsuda: possible to hide id?

MCC: just an idea.... long discussion about alternatives

ML: Discovery is just one aspect
... need to look into industrial use cases for example
... there are more aspects of lifecycle
... e.g., on boarding, off boarding
... suggest to call the activity "lifecycle"

MCC: different work item in charter
... w.r.t. to discovery and industrial... there might be areas where needed but others where not needed
... discovery is entry point for on-boarding

ML: let's handle lifycyle in architecture

Taki: home use-case.... we gonna have profile
... we have to think about discovery in smart home

MCC: profile should specify consumer setup

ML: guidelines for implementations

ZK: on-boarding depends on underlying protocol

MCC: specification for discovery is actually a TD describing the service

Kaz: discussion reminds me of discussion in DID
... should keep up the discussion

MCC: Actions
... create discovery repo (even though charter has not been approved yet)
... start with use cases and requirements
... like to see firm status for Singapur IETF
... November 16-17

SK: being open to multiple query languages besides SPARQL
... or keyword searches

<kaz> [break till 3:05]

Architecture, Presenter: Michael Lagally

<kaz> scribenick: ege

mm: work items ?

ml: introduction to the architecture document for the observers
... (showing the issues page)
... no new issues since the last call of last week
... anybody thinking of an issue?

<kaz> WoT Architecture issues

mm: we are talking about the Proposed Recommendation release candidate

<kaz> Pullrequests

mm: looking at a PR request, number #385

<kaz> PR 385

mm: does security and privacy have any figures

<kaz> -> w3c.github.io/wot-architecture/#toc WoT Architecture Editor's Draft

mm: we have an issue about security metadata being ambiguous
... so the difference between the description/metadata so the securityDefinitions in the TD and the security data such as the keys/tokens

<kaz> Changes

<kaz> Preview

mm: figure 25 was also not consistent with the text

ml: we can fix this quickly
... (creates an issue about this)

mm: I can work onthis

<kaz> Issue 386

ml: shall I merge this PR?

<mlagally> https://github.com/w3c/wot-architecture/issues/380

mm: we have a meeting with privacy group tomorrow
... tomorrow 1pm

ml: if there are any outcomes from the discussion, please put into the issue

<kaz> agenda for PING joint session

<kaz> [Kaz notes that the meeting room for PING joint discussion will be this room, Koh on 3F.]

mm: consider that there are not blocking issues for the PR transition

RESOLUTION: The WoT WG does not have any blocking issues for PR transition of the architecture document

<kaz> ACTION: McCool to update the figure 25, 27-29 tonight

<trackbot> Created ACTION-181 - Update the figure 25, 27-29 tonight [on Michael McCool - due 2019-09-26].

now is the last day to decide to make change proposals for the specs before going to PR

ml: recapping from the last session to build the use cases
... (looking at the PRs of the w3c/wot repo)

<kaz> PR 862

<kaz> Rendered version

ml: (looking at the work charter draft to fill the architecture use cases)
... we should be cautious to not prescribe too many things
... any additional work items proposed by anyone?

mm: we need user categories, such as developer, device owner etc.
... we want to remove and revise some use cases
... once we fix the template I have mentioned in the previous talk, we can start using it to structure the use cases, user categories etc.

kaz: we should consider using workshop results and also maybe Shimmachi-san's input

mm: we need to be clear where we are prescriptive and where descriptive

kaz: don't forget the ideathon results

mm: I would have like to be invited, actually we should do it another time where some members of the working group join and explain some things we need
... using other STO for the terminology when possible

ml: (looking at issue 208 of architecture)

<inserted> Issue 208

ml: (now issue 25, WoT in a browser)

<inserted> Issue 25

mm: we need one browser vendor on board to do demo

<kaz> Issue 8

kaz: on Monday, there was a meeting of MEIG, and NHK made a presentation (and they're participating in WoT PlugFest too :), so I'd suggest we invite more people from MEIG, like Chris Needham BBC

mm: capturing RTSP cameras as Things

ml: there are already some specs out there who are about streaming

mm: making it sure to say that we are not defining our own media streaming protocol

ml: I will just create a new issue about data streaming
... we will collect all the issues with the defer to next spec version label in github
... slide on how to work on the profile document
... (explaining how scrum works)
... we should do scrum in order to get earlier feedbacks
... having sprints of 1 months for spec development

kaz: chris needham might come

he arrived!

ml: requirements for media

mm: chris, your view on IoT support for media devices

chris: we have dlna, hbbtv
... they are different standards but different capabilities

<kaz> [Kaz notes that there are three major hybrid TV mechanisms: HbbTV in Europe, ATSC in US and Hybridcast in Japan.]

kaz: let's find some use cases and present them at the monthly MEIG web meeting

ml: we don't know what this group is doing

mm: maybe we should both do an introductory presentation to each other

<kaz> MEIG intro

kaz: like controlling TVs from TD clients

mm: also audio devices

chris: using web to deliver richer experiences

<mlagally> @kaz, please share

<kaz> MEIG intro

kaz: presenting the presentation of MEIG

chris: we are heavily involved in the streaming support for the web
... moving this as much as possible to realtime

mm: we should dedicate more time into this presentation

<kaz> [proposal: joining the MEIG monthly call on Dec 3]

<kaz> ACTION: kaz to coordinate with Chris Needham about the expected joint call on Dec. 3

<trackbot> Created ACTION-182 - Coordinate with chris needham about the expected joint call on dec. 3 [on Kazuyuki Ashimura - due 2019-09-26].

Profiles

<mlagally> https://github.com/w3c/wot-profile

<kaz> scribenick: sebastian

Michael Legally shows the new wot-profile git repo

scribe: give some overview about the profile requirments document

https://github.com/w3c/wot-profile/blob/master/REQUIREMENTS.md

Michael McCool has PR about a new structure about the requirement document

PR can be found here https://github.com/w3c/wot-profile/pull/14

there is a template how the use cases should be defined

<kaz> REQUIREMENTS.md on McCool's repo

McCool explains about the interoperability requirement

scribe: go over all the requirments so far like complexity, devloper guidance, etc.
... composable profiles combines multiple profiles
... Validatible is new
... is about if TD satisfies a given profile
... Limit resources consumption requirement should limit the amount of resources
... you do not want to crash the consumer

ML: you may want to limit the resources on the Thing itself

McCool: there are two security requirements
... rejected requirement are documentd at the bottom of the document

ML: is going to merge the PR

<kaz> PR 14 merged

ML: shows the current strawman of the wot-profile

https://w3c.github.io/wot-profile/

<kaz> WoT Profiles Editor's Draft

McCool: we need a formal definition what a profile is
... requirement such as length of a string sould be go in the TD spec
... the table that have serialNumber, loc_lattitude should go in the TD spec
... nesting should be not that limited

ML: request to review the strawman

there is a discussion about the form of the current proposal of Oracle. It should be made clear that this is a member submission.

<taki> +q

<kaz> ["Member-SUBM" is the specStatus to be used]

<kaz> [but I think we should use "unofficial" for a while]

there should be no new terms defined in a profile. If so a new context has to be included.

we are not in the possition to define hard restrictions (e.g for text length), should be more relax.

ML: there are consumer on the market that always follow the lower limit

<kaz> (actual) Member Submission (member-only)

<kaz> [will have detailed discussion on the procedure offline]

Findings from Mozilla Web Thing

Ege is going to show Mozilla Web Thing REST API

<kaz> Ege's slides

ML: we do not have a description of the behavoir of events over WebSockets

ege: resources that can be created via an action can be deleted via DELETE

ege shows Mozilla's TD and an equivalent W3C TD

Mozilla defines an own sub-protocol

this has to be defined and be used in the W3C TD via the term "subprotocol"

ML: we should add behavior descriptions to the new charter Mybe not a TD topic

there is an issue from Kajimoto-san about cancel and update actions

ege: Mozilla's only address gateway use case.

Ml: can a gateway can communicate to a other gateway?

ege: don't know

<dape> ML: quick agenda checking

<dape> ... setting the scene

<dape> ... use cases & requirements

<dape> ... profile spec

<dape> ... findings from Mozilla Web Thing

Planning for tomorrow

<kaz> tomorrow's agenda

<kaz> mm: 16:30-17:00 for Profile

<kaz> ... and then 1h for Scripting

<kaz> ... 15:00-15:30 Web Things Protocol CG

<kaz> [day 1 adjourned; tomorrow's meeting starts at 8:30; group photo during the morning break]

<kaz> Meeting: WoT IG/WG f2f meeting during TPAC2019 in Fukuoka

<dezell> scribenick: dezell

TD Update

sebastian: Want to talk about status of TD and issues, and prioritization of issues.
... which much be addressed before PR, and which will addressed in our subsequent work.
... One issue came up yesterday regarding JSON-LD processing
... term "thing template" is new.

<sebastian> https://github.com/w3c/wot-thing-description/pull/811

sebastian: starting with JSON-LD PR
... (see Annex to the PR)
... D. JSON-LD Context Usage

McCool: is this issue aligned with what Verifiable Claims did? Class vs. Context?
... VC had a way of describing conflict resolution, and having the standard context first, etc.
... I think we should try to be consistent and steal from VC.

<kaz> fyi, Verifiable Credentials Data Model spec: https://www.w3.org/TR/2019/PR-vc-data-model-20190905/

McCool: seems like there are changes in-flight - should we allow additional time?

sebastian: no, I think now. 811 and 818 should really be addressed before PR.

<kaz> PR 811

<kaz> PR 818

sebastian: also 807.

ege: there are conflicts between assertion of server-data-schemas and extras.

McCool: today it says "server may send extra data" and "client should ignore it".
... if we change "assertions" is disruptive (may send us back to CR), but clarification is OK.
... (agreed, it's wording not normative content that needs changing.)

<kaz> Issue 807

McCool: objects can have extra fields (ignorable), oversized arrays are weird, but not necessarily impossible to deal with, so we could introduce wording.
... suggest - leave assertions alone, but put an explanatory note afterward.

kaz: we should add a section to the implementation report about the change for this issue 807 (adding clarification to some of the assertion)

McCool: essentially, it's "additonalProperties": true
... section 8.xxx add the explanation after the 4 assertions.

<kaz> preesnt+ Dave_Raggett, Ryo_Kajiwara, Yoshiaki_Fukami, Suguru_Washio, Hiroki_Endo, Shinya_Abe, Ege_Korkan, Takahisa_Suzuki, Sebastian_Kaebisch

McCool: should we merge the two PRs (811, 818) and approve this afternoon? (yes)
... for the next release, we should make certain things normative in the vocabulary. But not now.
... when we address templates this should happen automatically.

sebastian: next group of issues are feedback from a commenter (812, 817).

McCool: agreed - eventing is incomplete (but not wrong). Address after PR.

sebastian: For eventing, we have 3 terms defined - subscription, data, cancellation.
... for subscription, we have a request/response pattern.
... what happens if the subscription is set up using XML but JSON events are received - so more definition is needed.

McCool: will TD 1.1 be able to be backwardly compatible.
... we should reuse the pattern for "actions".
... we might return a URL to which we must refer in the cancellation.
... I think we can defer on defining some of these things, as long as we can address them without too much trouble later.
... we can reuse the expected-response pattern that's already defined.

ege: what about the XML subscription where JSON is returned?

McCool: it's a real corner case.

sebastian: I think we need to bring this issue to the forefront for our next meeting.
... I think that's all the considerations before PR.

McCool: yesterday, VC said that in order to have people overwriting content, @context needs to come first.
... do we already have an assertion for that?
... (yes).

s/I think we need an issue. It makes it mandatory, but not first today./I think we need an issue. It makes it mandatory, but not first today.

scribe: (nix that) ok, it already seems to be in the spec making it first.
... we have two versions due next year ~ a 1.1, and a 2.0. Have the issues been marked for maintenance (1.1) vs. subsequent?

sebastian: Question is "what belongs to maintenance..."

McCool: please check the WG charter to do a level set. Map the work items in the charter to 1.1 or 2.0
... specifically, do Thing Templates go in maintenance or subsequent?
... for every suggested new data item, we need an issue. Should be investigated (adopt external definitions?) and assigned to a release.

<kaz> Issue 806

McCool: the label "Defer to next TD spec version" needs to be clarified as maintenance or not.

<kaz> [break till 10:05]

<taki> scribe: TK

<taki> scribenick: taki

Binding Templates

McCool: Review and update use cases and requirements. template will be available.
... 2 phases. publication resolution, and maintenance.
... identify things for protocol bindings.

Ege: whether we can publish or not. I summerized what needs to be done, status, etc.
... gonna give overview.
... Issue 6 and 3. what is everyone expecting from protocol binding.
... #6. old issues. there is a nice list of things to be done.
... about forms field, and how it maps to protocols such as REST.

Sebastian: we also have global form.

McCool: there is TD template.
... and security definition are part of binding.
... TD template may not contain URL.
... this is a longer term issue.

<igarashi> zakim. what is agenda?

McCool: we can review what is in form.

Sebastian: we call "protocol template"

McCool: terminology issue.

Sebastian: officially "Protocol template"

Ege: "Protocol Binding Template" is the official name.

Sebastian: we do not define concrete binding.

McCool: we can have shorter term. "Protocol Template" is fine.
... binding is implementation.

Ege: GitHub calls "Binding Templates"

Sebastian: we can check charter.

McCool: we published Note already.
... we cannot really change title now.
... we can publish at different URL. should check with Kaz.

Kajiwara: 2016 charter says "Binding Templates"

McCool: we have various short names.
... I will use a full name in new charter.
... should discuss shorter name, and check with Kaz if we can change URL.

Washio: architecture document says "Binding Templates"

McCool: we can say "Binding Templates"
... it contains security binding as well.
... there are options and pros & cons.

Ege: issue #1
... is this relevant?
... e.g. OneM2M

Sebastian: Matthias should answer the question.

McCool: discussed with Ericsson on OneM2M.
... It would be best if Ericsson can join us and help.

Sebastian: I can take care of OPC-UA.

McCool: I and Koster can contribute on OCF.
... The baseline is HTTP. CoAP and MQTT.

Dave: OMG has stuff.

McCool: DDS
... we can also describe practice to bridge to bacnet. echonet, etc.

Sebastian: are we trying to come up with wish list?
... OPC-UA stuff should be done in OPC-UA. It is protocol plus datamodel.

McCool: priority for this release is HTTP, CoAP and MQTT.

Sebastian: we can describe there are more protocols but we do not maintain those standards.

McCool: binding template is about practice.
... HTTP/CoAP/MQTT and variants. and there are DDS.
... OPC-UA mapping to HTTP. vs mapping directly to OPC-UA protocol.
... needs plugin in Consumers.
... in the meantime, we can suggest to use bridge.
... XML was not tested yet.

Ege: I grouped issues into 4. payload, concrete protocol, pseudo protocol and others.

McCool: I would say "variant protocol". it is a particular way to use it. It is a subprotocol.

Ege: Payload. XML is done. CBOR is not there. Issue 8.
... What about others?

McCool: OCF uses CBOR, it is important.

Sebastian: EXI is heavily used in e-mobility.

McCool: and there are type integer, type string, etc.

Ege: clients can also use text/plain.

McCool: we can interpret as JSON types.

Ege: next, concrete protocol. MQTT and CoAP binding needs to be fixed.
... MQTT binding uses codes now. This is strange. There is an example in TD spec as well.

Sebastian: we should use identical names.

McCool: we have vocabulary for each protocol.
... we can define for CoAP collaborating with IETF.

<kaz> Issue 14

Ege: MQTT has precondition. Connecting to broker returns credential.

Sebastian: we only support basic authentication, it is easy.

Ege looking at issue #14...

Sebastian: it is 3 years ago. we did not have security mechanism that time.

McCool: security metadata is there now.
... there is also MQTTS.

Ege: should I update MQTT vocabulary? It has impact in TD.

Sebastian: I cannot find anything in TD spec.

Ege: overhaul of MQTT vocabulary is going on.
... 3 should be "subscribe", etc.

<kaz> A.2 MQTT Binding

<kaz> Issue 43

Ege: interesting issue. CoAP multicast. issue #43.
... there is no comments on this issue.

McCool: should incubate first.
... worth discussing further.

Ege: issue #49. CoAP blockwise indicator.
... if nobody tries to use it, it does not make sense.

<kaz> Issue 49

Sebastian: CoAP has identifier. Protocol should manage itself.

McCool: TD can describe those, so consumer can know beforehand.
... We can talk with IETF.
... on Friday during next F2F.

Ege: Pseudo-protocol.
... Issue #15. this issue is 2 years old.

McCool: we can define at top level.
... Simplest way is to make it implicit.

Ege: Issue 40. Webhook.
... when we have more experimentation, we can expand description about Webhook.

McCool: there is dynamic URL issue.
... who has good test cases for Webhooks?

Ege: I do not know,

<kaz> Issue 40

Dave: there is Arena Webhub.
... it uses WebSocket.

McCool: CoAP on WebSocket.
... And there are other issues.

Ege: I will do editorial issues (MQTT).
... I need help from OPC-UA, CoAP and CBOR.

McCool: let's nail down on CoAP.
... we can publish, and still can make incremental update.

Ege: The examples were using old TDs.
... I think there is no reason for not publishing it now.
... the old version is wrong.

<Zakim> kaz, you wanted to talk about the URL/shortname

McCool explaining about short name and URL issue to Kaz...

Kaz: when we change short name, URL also can change.

McCool: we can drop "protocol" from name.

Kaz: sounds reasonable.

Sebastian: it is consistent with the current URL.

McCool: we need resolution.

<kaz> proposal: we'll change the title of "Web of Things Protocol Binding Templates" to "Web of Things Binding Templates"

Ezell: I misunderstood about binding.

McCool: it was also meant for ecosystems.

Ezell: it is cool.

<kaz> proposal (again): we'll change the title of "Web of Things Protocol Binding Templates" to "Web of Things Binding Templates"

McCool: any objections?

RESOLUTION: we'll change the title of "Web of Things Protocol Binding Templates" to "Web of Things Binding Templates"

McCool: make a resolution.
... Ege to implement this.

Dave: we could also add "description"

McCool: now on collaboration report.

<kaz> [NOTE: references to "Binding Templates" within related specs/notes should be also updated]

Collaboration Reports

<dsr> scribenick: dsr

sebastian talks about the role of @context in relation to new semantics

sebastian: everything is okay with the direction of JSON-LD following our discussion with the WG yesterday

Michael: the base directionality for string literals is something that can be addressed by JSON-LD without the need for a change to the underlying RDF core specifications.
... we should note this when we update the TD specification

Dave: incubation work on Easier RDF, e.g. RDF* are likely to take quite a while, and not impact the new WoT WG charter, but should be on our horizon.

Michael: I presented some ideas on WoT to the new Decentralized Identifiers WG. They are working on new URI schemes for identifiers

This could be useful to us, e.g. for identifiers for people

Michael: no joint meeting with internationalisation and accessibility groups during this TPAC

A brief report on the HTTPS Local network CG discussions

See: https://httpslocal.github.io/proposals/ and https://httpslocal.github.io/usecases/

There are two approaches, one using Wewb PKI and another using a shared secret

We’ve been working on what we call technically constrained certificates

A third approach uses application level tokens

A fourth approach uses device authority issued certificate

We may move to an IG or WG if there is sufficient interest from browser vendors

Michael: in the WoT IG/WG we need to look at these proposals and evaluate them

We may be able to cooperate on this with Mozilla and Google

Many specs depend on the concept of “origin” and a local network origin is something to consider

The linked docs are near final drafts

Michael: the WoT security task force is a good place for joint discussions on this

Which companies are implementing this?

Igarashi mentions that a guy from Toshiba is planning to implement.

Ryo Kajiwara was the presenter on behalf of the HTTPS Local CG.

Michael talks about the need for early review in respect to internationalisation

<kaz> Verifiable Credentials Data Model 1.0

sebastian: I can close the I18N issue and check back with Addison Philips

Logistics

<dape> scribe: dape

<sebastian> https://github.com/w3c/wot-thing-description/issues?q=is%3Aissue+is%3Aopen+label%3Ai18n-comment

<kaz> @@@will move the above link later

MCC: Next F2F in Singapore
... Intel can sponsor workshop and F2F
... you have to register for the IETF hackathon

<kaz> IETF 106 Hackathon Singapore

MCC: once it is full the registration will be closed and you are not able to go to the PlugFest
... we have several things we should collaborate with IETF

Kaz: WISHI Workshop registration needed as well?

MCC: Workshop is joint meeting with T2T research group
... plan to work on agenda for workshop
... can try to invite them to our main call

<kaz> IETF 106 Hackathon Singapore

<McCool> Singapore f2f wiki

MCC: see URL above for workshop and additional information
... Note: workshop and IETF in 2 different places
... Next^n meetings
... Vancouver in October
... Options: France, Finland, London
... do we plan to have 3 or 4 face-to-faces
... Next^3 in June, early July possible ?
... Next^2 March ?
... Discussed new task forces
... discovery, marketing, ...

<kaz> wot-marketing repo

MCC: doodle when we gonna have meetings

<dsr> IoT week takes place in Europe in June, e.g. Aarhus 17-21 June 2019. More details at https://iotweek.org/

MCC: marketing call should take place before main meeting
... 9pm Japan time (used to be security calll)
... tentatively set meeting to Monday, 9pm Japan times, 2 pm CET, .... after scripting
... discovery, after architecture call ? Let's do doodle....

Kaz: will do

MCC: next main call will be October 2nd
... next week we are not going to have any meetings
... charter discussions will take place in main call

Alan Bird: Globla bus developer leader

<kaz> [the doodle for wot-discovery will include several possible slots before/after wot-architecture call]

scribe: event "Impact IOT" in October 16th, Sidney
... attractive for W3C
... I commited going
... Question: Do we want to do a workshop?

<kaz> IoT Impact site

scribe: would like to see 2-3 people from the WoT group giving insigths
... please get in touch with me.. sooner than later
... great opportunity

MCC: Vendors or users

Alan Bird: City, companies, ..

SK: Interesting, but far away from Germany

<kaz> ACTION: kaz to allocate a webex call for wot-marketing on Monday, and generate a doodle including several slots on Thursday for wot-discovery

<trackbot> Created ACTION-183 - Allocate a webex call for wot-marketing on monday, and generate a doodle including several slots on thursday for wot-discovery [on Kazuyuki Ashimura - due 2019-09-27].

<kaz> @@@move the action later

MCC: Touches Marketing issues
... or at least to be setup for following opportunites

SK: Propose to work on slides maybe Alan can present...

Alan Bird: Have such a presentation

MCC: Should update presentation...
... short time frame

DSR: for slide set it is important to know the audience

Alan Bird: Not so much technology, .. but rather use-case... story telling

Kaz: slides from the breakout demo could be a basis for the description on the expected scenario and who did what

SK: too technical

MCC: use-cases, what is the business case
... even presentation time frame for the slides is tight
... maybe we can train you Alan...

Alan Bird: talk about the problem, lay out WoT, ...

MCC: please send us your presentation so that we can take this into account

<kaz> [lunch till 13:00]

<kaz> the room will be locked till 12:50

<taraw> +present

<kaz> scribenick: kaz

Privacy Joint Meeting

Issue 380

mm: privacy-related definitions based on ISO

Issue 386

mm: we don't have public security data to be distributed
... unfortunately, we do lack clear definition normatively
... that's what we have
... you can review it and give comments

tara: need to talk with another co-Chair

mm: 2 more weeks before make the resolution?
... note that we're fixing the pictures as well
... resolved terminology and figures
... we're generating new WG Charter

PR 862

rendered HTML

<toml> +q to say that it being partial isn't the full story

mm: 2 things doing
... (goes through "2. Scope")
... Discovery
... you need to fingerprint the TD for specific device
... having a unique identifier would be useful for that
... but we still have problem with fingerprinting TD
... we have a separate Note on Security and Privacy considerations
... use of context is an issue
... also distribution mechanism
... who would be an authorized user

<toml> -q

mm: we'll be pretty happy to identify topics to improve privacy handling for the new Charter
... and detailed description here (below)
... (goes to "2.7 Identifier Management")
... (and then shows slides on Discovery)
... this is just my personal idea at the moment
... [Requirements]

<toml> +q to ask what WoT wants to discuss with PING?

mm: directory-=based discovery and peer-to-peer discovery
... put devices in common privacy-preserving mechanism
... authenticate authorized users
... looking at mechanism by IETF, etc.
... 2-phase discovery
... introduction and exploration
... obtain address of directory service first
... then authentication
... also have other things related to directory service

McCool's slides on Discovery

mm: the other issue is self verification
... DID is interesting
... this is more about security issue
... also relevant to privacy that the gateway may sleep
... [Actions]
... collaboration discussion expected
... building new requirements
... plan to do a first chunk of considerations
... and would get more privacy review
... definitely would work on privacy early
... aim to present at IRTF T2TRG/WoT workshop

toml: walking through your plan document
... but the current document doesn't include improved portion

mm: that's correct
... the current version of TD is just a data model

toml: in that case, what would you talk with PING?

mm: would co-design the new version of WoT specs with you
... what is a good way to distribute information

sam: you might need to think about something...
... what's the danger with actual use cases?

mm: we've been considering security/privacy mitigation
... we can filter data if needed

<Zakim> toml, you wanted to ask what WoT wants to discuss with PING?

dsr: some application require rich information and some doesn't
... need to get permission

mm: that could be handled by the Profile topic

toml: fundamentally object to the specification

<dsr> users need to be able to make rational choices when granting pemission for limited exchange of information with privacy related information

toml: you want to add a whole bunch of identifiers...
... how is the home gateway handle the privacy?
... you should specify safe behavior

ch: you're going to specify what the gateway should do or should not do?

mm: Thing Description is description of data

<ryo-k> +q want to ask if the problem is in the TD itself or the discovery process

<taraw> MUD = "Manufacturer Usage Description" ?

sk: TD spec has a section for security and privacy considerations
... is this not enough?

sam: many Web sites ask personal information
... now we are generating some scheme for authorization
... WebAuthn is an example

<Zakim> weiler, you wanted to respond to DSR's example

mm: would like to clarify what the Thing Description does
... could include personal information possibly
... want to know what the device is like
... possible extension about location

<dsr> another example: “alexa turn on the light in my bedroom” which assumes that I have granted permission for the service to know about the lights in the rooms in my house

mm: very limited information
... what part of the information would be privacy information

<Zakim> ryo-k, you wanted to ask if the problem is in the TD itself or the discovery process

ryo: would like to understand the point
... the knowledge about you can access some device
... that could be a privacy information
... is the core question the TD spec itself? or rather about the discovery process?
... TD might have privacy-related information, though

sam: one of the issues is identifier

toml: super critical

sam: you have a unique identifier within all the TD files

kaz: @@@

toml: the core of the issue is that the privacy considerations section is non-normative...
... that is not mitigation

<Zakim> toml, you wanted to point out that non-normative "considerations" are not _mitigations_

toml: it is lisk introduction

mm: TD is data description to fit with the existing standards
... in the industry world, there are different requirements

<toml> +q to say that unless you limit the risk to the industrial use case_in the spec_ it is no limited like that

mm: we could generate another normative requirements

sam: we can't do mitigation there
... an example
... in the browser fingerprinting
... we have browser business and more
... to different domains

mm: profiles is in flying out
... they will in fact need home profile
... we can do normative privacy consideration
... but right now, TD is a copy of device template

sk: do you have any guideline document for privacy considerations?

tara: we have guideline documents :)

<toml> +q toml2 to ask what's "web"-y in WoT

mm: would put privacy considerations normatively to the expected profiles spec

taki: in the future, we need to think about concrete scenario to validate

<Zakim> toml, you wanted to say that unless you limit the risk to the industrial use case_in the spec_ it is no limited like that

tom: what you've been describing is exactly what I point out
... the mitigation needs to be included
... all the mitigations need to be included normatively

mm: can understand your point...

<Zakim> toml2, you wanted to ask what's "web"-y in WoT

tom: I don't know what is "web"-y in WoT...

<dsr> We should state strong guidance for implementations. Given that the URIs for Thing Descriptions are identifiers for things, e.g. in your home, one mitigation is to limit access to these identifiers to services that the user has given permission to. Another mitigation uses URIs that avoid leaking information about the kinds of devices. The thing description itself may include a much wider set if privacy sensitive information, so access to the contents of a thing descr[CUT]

<dsr> also needs to be subject to user permission.

dsr: why "Web" of Things above

remote+ Michael_Lagally

<zkis> remote+ Zoltan_Kis

<mlagally> :-)

<Zakim> weiler, you wanted to respond to dsr on giving permission

kaz: it sound like to me that a possible compromise might be the WoT WG's thinking about a possible normative description for privacy

sam: use cases of WoT are dangerous...

mm: one possible path
... we'll work on smart home
... define context
... we will define limitation within the profiles document
... normative privacy constraints are context-dependent

<mlagally> * Zakim, who is here?

tom: if you impose technical restriction which limit security risks
... that would be OK

mm: the question is actually it's not just about smart home
... could be smart city

ryo: we need to have one profile without any restriction as well?

mm: we have control

ml: one point
... we're defining a data format intended to be used for some specific purpose
... (mentions some possible use case)
... about medical alert which require person identification

sam: we're looking for mitigations

ml: something like recommended approach

mm: name could be used for identifier
... anyway we're end of the session
... we'll state the reasons why unique identifiers are important
... mandatory for TD
... database key

sam: are you aware of Mozilla's Prio system?

<hendo> miti

<inserted> @@@remove "miti" above

sam: privacy preserving system

tom: would be better to use software version instead of unique ID

<ryo-k> https://hacks.mozilla.org/2018/10/testing-privacy-preserving-telemetry-with-prio/

toml: sounds like we need further technical discussions

mm: right
... would think about what would be practical

tara: thank you for inviting us

(PING guys leave)

mm: we're kind of behind. do we want to do PR resolution now?

ml: could you summarize the story?

mm: in short, we are asked to have privacy consideration normatively

dsr: maybe we could make the current privacy section normative

kaz: yeah, that's exactly what I suggested to Tom :)

mm: we need to add assertions in that case

<dsr> and work with Tom & PING to get their agreement on the wording then move to PR

kaz: agree with Dave, and would suggest we consult with W3M
... also need to continue to talk with the PING guys to clarify if it's OK to make the privacy consideration section normative and extract additional assertions

mm: good thing is we'd have a better description for our privacy portion
... maintenance update and new profiles work in parallel
... profiles document would have detailed requirements
... the practical path seems to be making the current privacy section normative and extract assertions
... let's do some research and consult with PING again

ml: 2 things
... 1. timeline
... iteration might be going to take 6 months
... we're already extended
... Oracle is very concerned if we delay the publication for another 6 months

mm: if it's done by the end of this year, would it be OK?

ml: let me finish my 2nd point
... privacy regulation discussion in germany
... my point is there are regional laws and regulations
... we should think about what to be done as a data specification

mm: we don't have PII in TD at least normatively

ml: you want to identify devices

mm: would suggest here look at what kind of mitigation would be possible
... ways around this
... SSI, etc.
... encrypted identifier
... could be still decrypted

ml: not interactive TD?
... we could say "if you want to protect ID of some specific TD, please encrypted it"

<ryo-k> +q ryo-k on having "local" identifiers compared to "global" identifiers

mm: even with that we stil have issues
... we can have deeper discussion at another place
... need to get the specs done by the end of year

kaz: let's consult with Ralph!

mm: any objection?
... a. talk with Ralph
... b. deferring our decision about Proposed REC by at least 2 weeks

sk: should be less than 2 weeks

mm: could be 2 weeks minus 2 days, given our main call is on Wednesday

dezell: would like the plan
... we were very nice from the Code of Conduct viewpoint
... this horizontal review is very important
... we're talking about IDs, so in any case we have risks
... do we have words for preventing replay, etc.?
... TD is metadata
... actual data linked from it may have risks
... we need to make sure it
... good idea to talk with Ralph

sk: think we should show that we would like to do right thing

ml: TD spec is just defining data model
... actual protocol is out of scope

mm: we might want to revisit the security/privacy considerations
... anyway, we need to move on

ryo: one point
... my impression from the discussion was that they were looking at rather the protocol/network side rather than the TD data model itself

mm: I note fingerprinting
... also we do have issue
... let's move on

<Zakim> ryo-k, you wanted to comment on having "local" identifiers compared to "global" identifiers

WG charter

<sebastian> McCool: there is no pressure

<sebastian> ... there is a PR from Michael Legally

Rendered HTML of McCool's PR for the draft WG Charter

<sebastian> ... McCool: we will take care of interoperability profile

<sebastian> ... we should definitly consider privacy

<scribe> scribenick: ryo-k

dsr: describe "onboarding of devices" in the charter

(looking at wot-architecture PR #879)

<inserted> PR 879

ml: currently we only have discovery
...: but don't have onboarding of devices
... we should investigate on what we can define in the document
... we need to define specific terms
... clarifications of profiles

mm: suggesting user confirmation in the home environment. remove automatic part, describe automatic and confirmational onboarding mechanism

sk: what do you mean by onboarding

mm: associating a device to a gateway, getting it into a security perimiter

dsr: we should define terms before we use them

mm: have the definition of onboarding (and device lifecycle) in the slides but not in the documents. we can move them to the documents

ml: it's about minimizing onboarding (not inserting long numbers, instead use a dip switch or so...

mm: TDs are descriptive, but everything in wot does not have to be descriptive like the TD
...: Directory also acting as the onboarding service

ml: need to describe it in the specification

mm: where does it go in the spec? architecture? discovery?
...: "how do you associate a device with a discovery service" is onboarding
... ask Sam Weiler what the missing pieces in the spec are (for a privacy review

mm: going forward: accept my PR, leave ml's PR open for comments

ml: propose to merge both PRs then review the whole document

mm: want to see the diff of the HTML (created by both PRs)
... okay with merging both PRs, it's a draft so it can be reviewed later
... need more discussion before making a resolution

sk: the other PR?

PR #862?

mm: see no objections, merging both PRs
...: has conflicts...

ml: 8 conflicts, so I will take on fixing

dape: did we talk about incubation topics?

mm: not yet
... (use case - protocol bindings) belong in working group,
...: (scripting - script packaging) belong in incubation,
... developer's guide, best practice documents belong in IG

(note: talking about section 3.2 of wg charter 2019 draft http://w3c.github.io/wot/charters/wot-wg-charter-draft-2019.html)

<inserted> kaz: notes that Use cases and requirements document could be also done by the IG, and the current proposed IG Charter which is on the AC review does include it :) http://w3c.github.io/wot/charters/wot-ig-2019.html#deliverables

mm: make Use Case and Requirements documents an IG document

dape: any downside of being WG document or the other way around?

mm: WG mainly works on REC track normative deliverables
...: for scripting, we need to first find mechanism of deployment

dape: isn't IG charter fixed?

mm: IG charter is now on AC review. we can request a change

kaz: we can publish an informative IG note any time

mm: First five items only will be in the working group charter, others will be removed from the charter

zk: Webof Things specifically for edge computing?

mm: one example of WoT can be. thinking of WoT as orchestration mechanism
...: we can start incubating those use case

zk: understand Scripting being out of WG scope, because it seems like there is not enough motivation in the group

dape: it says "non-normative" and "may", so there isn't a need for formal objection (of including/excluding Scripting

zk: CGs can create notes, then they can be picked up by WGs later]

mm: true. many famous specs are still in CG, and CG can involve non-W3C members' work

kaz: clarification - CG reports, not notes. also, UC/Req docs in WG?

mm: Final requirement document is in the WG part. IG can input on them though

(break, come back at 1600)

mm: make privacy "mitigation" section, make them normative, use "should" for now
... privacy mitigations in both TD and Discovery; ID format is in TD, the distribution is in Architecture/Discovery
... week of bulldozing, review, fixing stuff, then review, ...

dsr: we may need somebody in the room to do hands on work

(talks on getting PR to resolution; how to handle privacy reviews)

<kaz> proposal: we'd like to make the privacy consideration section normative and extract additional assertions, and then publish an updated CR mid October. and would see if that would be OK by the Director and the PING

<kaz> sk: suggests we have the main call next Wed though we could skip the TF calls

<kaz> proposal2: we'd explore to make the privacy consideration section normative and extract additional assertions, and then publish an updated CR mid October. and would see if that would be OK by the Director and the PING

RESOLUTION: we'd explore to make the privacy consideration section normative and extract additional assertions, and then publish an updated CR mid October. and would see if that would be OK by the Director and the PING

<kaz> mm: we'll skip the WebTHing CG discussion, will talk about that during the main call

<kaz> ml: should involve Ben

<kaz> mm: ok. let's do that during the main call

TD extension

<kaz> scribenick: McCool

TD extensions

<inserted> @@@slides tbd

sebastian: shares new features for thing description 1.1/2.0
... shares munich workshop outcomes
... security schemes, link relations, full JSON data schema
... additional features too, recurrence of data schema definitions
... get a lot of duplicates when different interactions depend on the same payload structure

mccool: probably want to parallel the securityDefinitions construct

sebastian: add "definitions" to top level, a map of data schemas
... then use $ref to refer to them

ege: would have to do a flattening process before validation

ack

lagally: think it is a good idea, but...

,,, some considerations

scribe: have a plan to define aggreggations of things, need to avoid name conflicts, same name in different things
... same issue with thing templates, if a thing implements multiple templates
... if have definitions with the same name, need to figure out how to handle name scopes

sebastian: thing solved by $ref, since requires URLs and JSON pointers

lagally: incorporated descriptions might change?

mccool: superclass brittleness problem
... maybe also have $refs for securityDefinitions? Not necessary, just a thought

sebastian: another issue, missing "observeall"
... another example would be just the differences
... then there is the problem of a dynamic structure
... that is, a generated resource with a dynamically generated url

ege: should reformat ops into table form, also need observemultiple
... and for mozilla, they "request" an action, don't invoke

sebastian: main point is we should extend our op list

mlagally: async vs. sync?

zkis: execute vs trigger

mccool: but we do agree there is a semantic difference
... in these ways to invoke/request actions

sebastian: another topic, binary TDs
... could support binary serialization, EXI4JSON or CBOR
... to support constrained devices

mccool: another issue, canonicial serialization, important for signing

<inserted> scribenick: kaz

ml: we should look into which direction to go for business cases
... should understand the scenario

sk: it's more relevant for 2.0 rather than maintenance

(16:50)

<mlagally> mlagally suggests that we do an IG analysis first for relevant business driven use cases to select candidates for the binary format.

sk: can we go into the remaining PRs?

mm: 1 hour for TD including TD next steps

profiles

<scribe> scribenick: McCool_

<scribe> agenda: issues, process, roadmap, scope and timing

mlagally: issues would take a lot of time to look at in detail, so will just do a quick overview
... would like to ask people to review issues and add comments
... looking at issue tracker
... nested structures, agree can't do, need better approach

<kaz> wot-profile issues

mlagally: split data model approaches make sense

<inserted> issue 4

mlagally: profile name

<inserted> issue 5

mlagally: recommended security
... needs more discussion, dependency on use case and vertical
... issue 7 is a "scope" topic, need to better define
... issue about "do we need vertical profiles or composition"

<inserted> issue 7

mlagally: issue about twin profiles being a bad example
... question about which spec the "core data model" goes

<inserted> issue 8

mlagally: whether reference in binding spec or merge into binding templates

<inserted> issue 11

mlagally: http protocol binding duplicated

<inserted> issue 13

mlagally: issue about identifying profiles via validation
... if there are additional issues, should write down

sebastian: need to go back to use cases and requirements
... a little concerned that we are working on something for the next charter without having finished the current charter

mlagally: however, lack of interoperability is a serious problem

mccool: I think we need to focus on getting the use cases and requirements and scope done well
... but don't spend time on small details in the current draft

mlagally: can start with constraints on HTTP

mccool: I think we understand the use cases and users sets first

mlagally: scope
... definitely need to define templates
... and if core name causes contentions

mccool: if interoperability is the main problem, let's focus on that
... templates can go into the updated TD spec

dsr: use case is very important

mccool: what is the definition of interoperability

ege: main issue is we can't define a generic client

mccool: I think we need to be laser focused on interoperability, and also define it well

sebastian: interoperability is hard to define
... as a developer, have many design choices
... but have a problem of knowing what capabilities the consumer will have

mlagally: example, analytics going to the cloud
... suppose you are a device manufacturer
... today you have implement different data types and protocols for each cloud target
... if there are 4 targets, 4 times the implementation

sebastian: but what if they are not talking to the cloud?
... would not like to support 10 different profiles

mlagally: alternative, here is a TD, does not work...

mccool: I suggest we define profiles as the set of requirements for consumers
... and from that define requirements on TDs

kaz: we definitely need to generate a use case and requirements document

mlagally: let's look at a simple template...
... going to upload what I've captured during this discussion, will upload to repo
... let's continue next time with use cases and requirements

Scripting API

<kaz> scribenick: ege

dp: update on scripting api, together with zoltan
... here is a timeline of the scripting api evolution
... now coming simplified scripting api
... (presenting the slides)
... start with the WoT object
... consume produce and discover objects
... blue fields are used to pass options to the requests, such as uriVariables
... now exposed part
... discovery has not been tested yet

ml: how is security done in the consumed thing?

mm: not done in the api

zk: runtime has to do it

dp: a runnning example is needed to show what scripting api does
... node-wot is the de-facto implementation
... you can contribute, you can write your own binding
... you can also use it for td parsing etc.
... it is available in an online version as well
... I will start with the server side
... (explains the code demo)
... (launches the server and client)
... (shows the browser version)

dr: we should reference these kind of projects in the landing page as well

<dsr> We should talk about how to link to WoT implementations from the landing page(s) in the marketing task force

mm: not enough time for zoltan
... is it ok if we give you 30 minutes in the main call

zk: sure it makes sense

mm: we need to give high priority to the ping comments

toru: yamada-san will be leaving the working group
... and I will have less time to contribute

mm: thank you for your contributions

(everybody claps!)

ml: thanks everyone who showed the Oracle demo during the TPAC

mm: adjourned

- DRAFT -

Web of Things F2F, TPAC 2019

20 Sep 2019

Attendees

Contents