<dsr> scribenick: dsr
Michael does some agenda bashing including ideas for future F2F locations.
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
... second, yesterday’s voice assistant breakout touched upon relation to WoT
McCool: we don’t yet have a work item on accessibility
Dave: this is an opportunity to bring in some accessibility experts into the WG
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> Shimmachi-san's Slides
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
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
David: 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
David: how do you differentiate a use case from a user story?
Michael: a use case is more formal
David: 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
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.
Dave: 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)?
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
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
Sebastian: 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
Sebastian: 2 topics here
... container object for TD security definition
... and
... note on the difference between a JSON-LD context and an RDF
vocab
Ivan: magic source :)
Sebastian: what are the LD features, etc.
McCool: one more thing about JSON vs
JSON-LD
... maybe would add a new feature?
Sebastian: wot architecture issue?
McCool: right
... nice to consider that issue as well
Ivan: 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
Sebastian: 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
Sebastian: 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
Sebastian: (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)
Gregg: inline or embed
McCool: question is
normalization
... normalized version may be clean
Sebastian: update context by included
nodes
... sounds good
Gregg: note that not included in the context any more
azaroth: options to offer inline or embed
Sebastian: 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
Gregg: 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
Sebastian: 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
McCool: 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
Ivan: you define constraint
... it's a super version of abbreviation
... not only listing but describing
McCool: 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
McCool: good example is security
vocabulary
... now we're using JSON Schema
... problem with additional features
... how to validate the extensions
Ivan: 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
Sebastian: another question on JSON vs JSON-LD?
McCool: yes, that's our priority
Sebastian: shows issue 371
... TAG interoperability concerns
... do you have the same problem?
bigbluehat: you can use any names for your local vocabulary
McCool: 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"
Gregg: core usage of JSON-LD is you take the data
McCool: 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)
Gregg: 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
Sebastian: we're responsible how it should be done
Kaz: do we want to explain that to David?
McCool: make response on GH?
Ivan: btw, 2 more weeks for JSON-LD CR :)
Gregg: 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
Sebastian: do you have an example?
ms: Verifiable Credentials Data Model
Verifiable Credentials Data Model
Ivan: if people want to use the basic capability don't need to use JSON-LD
<dape> scribe: dape
McCool: 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
McCool: "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
McCool: 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
McCool: Alignment with existing
standards
... get others on board, e.g., IETF core resource directories
... core link format
... 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.
McCool: well-known/td could be used as a "known" entry point
Dave: how can I advertise a service that can be tight to a device?
McCool: discussion with Zoltan about management API
Dave: we need to look at this broader aspect.. incubation is good with that regard
McCool: 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
Lagally: where are these requirements coming from?
McCool: 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
McCool: 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
McCool: It is ok to have
diversity
... directory should be strict about authentication
... will write up requirements document to discuss
Matsuda: possible to hide id?
McCool: just an idea.... long discussion about alternatives
Lagally: 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"
McCool: 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
Lagally: let's handle lifycyle in architecture
Taki: home use-case.... we gonna
have profile
... we have to think about discovery in smart home
McCool: profile should specify consumer setup
Lagally: guidelines for implementations
ZK: on-boarding depends on underlying protocol
McCool: specification for discovery is actually a TD describing the service
Kaz: discussion reminds me of
discussion in DID
... should keep up the discussion
McCool: 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
Sebastian: being open to multiple query
languages besides SPARQL
... or keyword searches
<kaz> [break till 3:05]
<kaz> scribenick: ege
McCool: work items ?
Lagally: 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
McCool: we are talking about the Proposed Recommendation release candidate
<kaz> Pullrequests
McCool: looking at a PR request, number #385
<kaz> PR 385
McCool: does security and privacy have any figures
<kaz> -> w3c.github.io/wot-architecture/#toc WoT Architecture Editor's Draft
McCool: 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
McCool: figure 25 was also not consistent with the text
Lagally: we can fix this quickly
... (creates an issue about this)
McCool: I can work onthis
<kaz> Issue 386
Lagally: shall I merge this PR?
<mlagally> https://github.com/w3c/wot-architecture/issues/380
McCool: we have a meeting with
privacy group tomorrow
... tomorrow 1pm
Lagally: 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.]
McCool: 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
Lagally: 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
Lagally: (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?
McCool: 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
McCool: we need to be clear where we are prescriptive and where descriptive
Kaz: don't forget the ideathon results
McCool: 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
Lagally: (looking at issue 208 of architecture)
<inserted> Issue 208
Lagally: (now issue 25, WoT in a browser)
<inserted> Issue 25
McCool: 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
McCool: capturing RTSP cameras as Things
Lagally: there are already some specs out there who are about streaming
McCool: making it sure to say that we are not defining our own media streaming protocol
Lagally: 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!
Lagally: requirements for media
McCool: 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
Lagally: we don't know what this group is doing
McCool: maybe we should both do an introductory presentation to each other
<kaz> MEIG intro
Kaz: like controlling TVs from TD clients
McCool: 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
McCool: 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].
<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
Lagally: 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
Lagally: is going to merge the PR
<kaz> PR 14 merged
Lagally: 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
Lagally: 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.
Taki: we are not in the possition to define hard restrictions (e.g for text length), should be more relax.
Lagally: 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]
Ege is going to show Mozilla Web Thing REST API
<kaz> Ege's slides
Lagally: 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"
Lagally: 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.
Lagally: can a gateway can communicate to a other gateway?
Ege: don't know
<dape> Lagally: quick agenda checking
<dape> ... setting the scene
<dape> ... use cases & requirements
<dape> ... profile spec
<dape> ... findings from Mozilla Web Thing
<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
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 Description 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
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]
<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
<sebastian> https://github.com/w3c/wot-thing-description/issues?q=is%3Aissue+is%3Aopen+label%3Ai18n-comment
<dape> scribe: dape
McCool: Next F2F in Singapore
... Intel can sponsor workshop and F2F
... you have to register for the IETF hackathon
<kaz> IETF 106 Hackathon Singapore
McCool: 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?
McCool: 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
<kaz> IETF 106 Hackathon Singapore
<McCool> Singapore f2f wiki
McCool: 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
McCool: doodle when we gonna have
meetings
... 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
McCool: 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
<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> [the doodle for wot-discovery will include several possible slots before/after wot-architecture call]
<dsr> IoT week takes place in Europe in June, e.g. Aarhus 17-21 June 2019. More details at https://iotweek.org/
<kaz> IoT Impact site
Alan_Bird: Globla bus developer leader
... event "Impact IOT" in October 16th, Sidney
... attractive for W3C
... I commited going
... Question: Do we want to do a workshop?
... would like to see 2-3 people from the WoT group giving insigths
... please get in touch with me.. sooner than later
... great opportunity
McCool: Vendors or users
Alan: City, companies, ..
Sebastian: Interesting, but far away from Germany
McCool: Touches Marketing
issues
... or at least to be setup for following opportunites
Sebastian: Propose to work on slides maybe Alan can present...
Alan: Have such a presentation
McCool: Should update
presentation...
... short time frame
Dave: for slide set it is important to know the audience
Alan: 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
Sebastian: too technical
McCool: use-cases, what is the
business case
... even presentation time frame for the slides is tight
... maybe we can train you Alan...
Alan: talk about the problem, lay out WoT, ...
McCool: 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
<kaz> scribenick: kaz
McCool: privacy-related definitions based on ISO
McCool: 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 as well
McCool: 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
<toml> +q to say that it being partial isn't the full story
McCool: 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
McCool: 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?
McCool: 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: 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
Tom: walking through your plan
document
... but the current document doesn't include improved
portion
McCool: that's correct
... the current version of TD is just a data model
Tom: in that case, what would you talk with PING?
McCool: 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?
McCool: 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?
Dave: some application require
rich information and some doesn't
... need to get permission
McCool: that could be handled by the Profile topic
Tom: 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
Tom: you want to add a whole
bunch of identifiers...
... how is the home gateway handle the privacy?
... you should specify safe behavior
Christine: you're going to specify what the gateway should do or should not do?
McCool: 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" ?
Sebastian: 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
McCool: 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
McCool: 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
Tom: super critical
Sam: you have a unique identifier within all the TD files
Kaz: @@@
Tom: 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_
Tom: it is lisk introduction
McCool: 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
McCool: 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
McCool: 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
Sebastian: 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
McCool: 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
McCool: 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.
Dave: why "Web" of Things above
<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...
McCool: 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
McCool: 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?
McCool: we have control
Lagally: 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
Lagally: something like recommended approach
McCool: 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?
... 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/
Tom: sounds like we need further technical discussions
McCool: right
... would think about what would be practical
Tara: thank you for inviting us
(PING guys leave)
McCool: we're kind of behind. do we want to do PR resolution now?
Lagally: could you summarize the story?
McCool: in short, we are asked to have privacy consideration normatively
Dave: maybe we could make the current privacy section normative
Kaz: yeah, that's exactly what I suggested to Tom :)
McCool: 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
McCool: 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
Lagally: 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
McCool: if it's done by the end of this year, would it be OK?
Lagally: 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
McCool: we don't have PII in TD at least normatively
Lagally: you want to identify devices
McCool: would suggest here look at
what kind of mitigation would be possible
... ways around this
... SSI, etc.
... encrypted identifier
... could be still decrypted
Lagally: 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
McCool: 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!
McCool: any objection?
... a. talk with Ralph
... b. deferring our decision about Proposed REC by at least 2
weeks
Sebastian: should be less than 2 weeks
McCool: could be 2 weeks minus 2 days, given our main call is on Wednesday
David: 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
Sebastian: think we should show that we would like to do right thing
Lagally: TD spec is just defining data
model
... actual protocol is out of scope
McCool: 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
McCool: 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
scribenick: sebastian
McCool: there is no pressure
... there is a PR from Michael Legally
Rendered HTML of McCool's PR for the draft WG Charter
McCool: we will take care of interoperability profile
... we should definitly consider privacy
<scribe> scribenick: ryo-k
Dave: describe "onboarding of devices" in the charter
(looking at wot-architecture PR #879)
<inserted> PR 879
Lagally: 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
McCool: suggesting user confirmation in the home environment. remove automatic part, describe automatic and confirmational onboarding mechanism
Sebastian: what do you mean by onboarding
McCool: associating a device to a gateway, getting it into a security perimiter
Dave: we should define terms before we use them
McCool: have the definition of onboarding (and device lifecycle) in the slides but not in the documents. we can move them to the documents
Lagally: it's about minimizing onboarding (not inserting long numbers, instead use a dip switch or so...
McCool: TDs are descriptive, but
everything in wot does not have to be descriptive like the
TD
...: Directory also acting as the onboarding service
Lagally: need to describe it in the specification
McCool: 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
McCool: going forward: accept my PR, leave ml's PR open for comments
Lagally: propose to merge both PRs then review the whole document
McCool: 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
Sebastian: the other PR?
PR #862?
McCool: see no objections, merging
both PRs
...: has conflicts...
Lagally: 8 conflicts, so I will take on fixing
Daniel: did we talk about incubation topics?
McCool: 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
McCool: make Use Case and Requirements documents an IG document
Daniel: any downside of being WG document or the other way around?
McCool: WG mainly works on REC track
normative deliverables
...: for scripting, we need to first find mechanism of
deployment
Daniel: isn't IG charter fixed?
McCool: IG charter is now on AC review. we can request a change
Kaz: we can publish an informative IG note any time
McCool: First five items only will be in the working group charter, others will be removed from the charter
Zoltan: Webof Things specifically for edge computing?
McCool: one example of WoT can be.
thinking of WoT as orchestration mechanism
...: we can start incubating those use case
Zoltan: understand Scripting being out of WG scope, because it seems like there is not enough motivation in the group
Daniel: it says "non-normative" and "may", so there isn't a need for formal objection (of including/excluding Scripting
Zoltan: CGs can create notes, then they can be picked up by WGs later]
McCool: 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?
McCool: Final requirement document is in the WG part. IG can input on them though
(break, come back at 1600)
McCool: 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,
...
Dave: 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
scribenick: kaz
McCool: we'll skip the WebTHing CG discussion, will talk about that during the main call
Lagally: should involve Ben
McCool: ok. let's do that during the main call
<kaz> scribenick: McCool
<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
Lagally: think it is a good idea,
but... some considerations
... 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
Lagally: async vs. sync?
Zoltan: 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
Lagally: we should look into which
direction to go for business cases
... should understand the scenario
Sebastian: 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.
Sebastian: can we go into the remaining PRs?
McCool: 1 hour for TD including TD next steps
<scribe> scribenick: McCool_
<scribe> agenda: issues, process, roadmap, scope and timing
Lagally: 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
Lagally: split data model approaches make sense
<inserted> issue 4
Lagally: profile name
<inserted> issue 5
Lagally: 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
Lagally: issue about twin
profiles being a bad example
... question about which spec the "core data model" goes
<inserted> issue 8
Lagally: whether reference in binding spec or merge into binding templates
<inserted> issue 11
Lagally: http protocol binding duplicated
<inserted> issue 13
Lagally: 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
Lagally: 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
Lagally: can start with constraints on HTTP
McCool: I think we understand the use cases and users sets first
Lagally: 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
Dave: 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
Lagally: 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
Lagally: 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
Lagally: 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
<kaz> scribenick: ege
Daniel: 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
Lagally: how is security done in the consumed thing?
McCool: not done in the api
Zoltan: runtime has to do it
Daniel: 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)
Dave: 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
McCool: not enough time for
zoltan
... is it ok if we give you 30 minutes in the main call
Zoltan: sure it makes sense
McCool: 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
McCool: thank you for your contributions
(everybody claps!)
Lagally: thanks everyone who showed the Oracle demo during the TPAC
McCool: adjourned