- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 15 Feb 2021 21:48:53 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2021/02/01-wot-discovery-minutes.html
also as text below.
Thanks a lot for taking the minutes, Christine!
Kazuyuki
---
[1]W3C
[1] https://www.w3.org/
WoT Discovery
01 February 2021
[2]Agenda. [3]IRC log.
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Discovery_WebConf#1_February_2021
[3] https://www.w3.org/2021/02/01-wot-discovery-irc
Attendees
Present
Andrea_Cimmino, Christian_Glomb, Christine_Perey,
Cristiano_Aguzzi, David_Ezell, Farshid_Tavakolizadeh,
Kaz_Ashimura, Kunihiko_Toumura, Michael_McCool,
Tomoaki_Mizushima
Regrets
-
Chair
McCool
Scribe
cperey
Contents
1. [4]Previous minutes
2. [5]Quick updates
3. [6]Implementations
4. [7]wot-security issue 196 - Consider security issues in
Discovery
5. [8]PR 107 - Update SPARQL DDoS ed note
6. [9]PR 112 - Describe the information model
Meeting minutes
Previous minutes
<kaz> [10]Jan-25
[10] https://www.w3.org/2021/01/25-wot-discovery-minutes.html
McCool: review minutes of January 25 meeting
McCool: we haven't done anything to follow up on last week's
actions
McCool: asks Kaz if reached out to liaison
Kaz: yes, just starting on liaison stuff
McCool: we looked at PRs
McCool: probably take care of some these open items today and
we did talk about some of these things during security meeting
McCool: any objections to approving minutes? hearing none, they
are published
Quick updates
McCool: quick updates: nothing in particular. Liaison still in
progress
McCool: maybe one thing to consider: if we did a geospatial
ontology were required for WOT discovery
McCool: might make sense to make that a joint standard with
OGC. Might be useful
McCool: start floating that idea?
Kaz: start with simple liaison
Kaz: if needed, we can switch with memorandum
McCool: OK. Let's arrange a meeting with OGC people, once we've
written the strawman
Kaz: existing vocabulary and ontology would be best, we just
refer to it
McCool: ok let's table for now
Implementations
McCool: any other quick updates?
McCool: where are we with implementations: path but not SPARQL
McCool: andrea was working on one with SPARQL
Farshid: we also need implementations
McCool: timeline for implementation is running behind but we
need to get done by end of summer
Andrea: Implementation we are working on covers JSON and SQARQL
path
McCool: will you implement implementation?
sorry...
will not implement SPARQL
Andrea: we will focus on
from Siemens: internally, we're discussing and will report next
week
Cristiano: we are working on a SPARQL implementation but not
getting back from RDF
Cristiano: we have a student working on this and wasn't able to
resolve the problem.
Andrea: we are giving back LD but there is a blocking issue
McCool: let's check to see if already captured this as an
issue... checking
McCool: looks like it is issue #1015
<McCool> [11]wot-thing-description Issue 1015 - Problems
translating TDs from JSON-LD 1.1 to RDF and back
[11] https://github.com/w3c/wot-thing-description/issues/1015
McCool: Going to label this one
McCool: ... as discovery
… and raise its importance
McCool: label called "blocker"
McCool: I'll try to make sure that we have this in the
discussions
McCool: Siemens will do SPARQL and assuming also doing A-Frame
McCool: Add the issue number
McCool: anything else about implementation status?
McCool: want to track implementations more clearly in the
future
McCool: where should we track? in discovery under testing?
McCool: where to describe implementations? in the readme.md I
think we want to add implementations section
McCool: there will be 3 implementations. A short paragraph
about each. Don't want to clutter up the Readme or have too
much
Farshid: there is a directory called "prior work"
McCool: an implementation must follow the spec
Farshid: right but transfer that over
McCool: what we should do is create new directory called
"Readme" and have in it the names
McCool: Fraunhofer linkSmart, and put URL, copy later
McCool: Univ of Madrid implementation
Andrea: UPM OEG
<acimmino> andrea cimmino, Universidad Politecnica de Madrid
(UPM, OEG)
McCool: has JSON, X-path and SPARQL
McCool: finally another one from Siemens
McCool: is it OK to write in here. Do you intend to support the
full standard, including all three?
Christian: JSON for sure, and SPARQL
McCool: more than good enough
McCool: later we can create other files to link to different
things, LinkSmart, UMP OEG,
McCool: do you have a name for implementation yet?
Andrea: not yet
Christian: do the implementations be made publicly available?
or enough if internal
<kaz> [12]WoT Discovery implementation page
[12] https://github.com/w3c/wot-discovery/blob/master/implementations/README.md
McCool: doesn't have to be open source or anything just for
adoption
McCool: ideally, we need one full implementation for open
source
McCool: right now the only one is UPM
Andrea: do we want to include other things in the
implementation (more than only search, also management
implementation which we may or may not do)
McCool: end of the day we need two of everything
McCool: doesn't have to be super performant, but for adoption
purposes. Open source is not a requirement
McCool: if available, people could use open source code
McCool: but if you include a feature that's only useful in a
factory setting, that's OK too
McCool: leave up to the rest of you to do PRs, and the rest
Toumura: We should also track introduction mechanism
McCool: right, so what we should do is look at current spec...
implementations of directories
McCool: in addition, the following introduction mechanisms are
supported
McCool: we have DNS-SD, SD under MDNS
McCool: and we should have a description of each of those
McCool: Apache
McCool: in this case, we have to demonstrate each of them
McCool: direct URL support as well
McCool: so we'll have to fill this out
McCool: Link to over to WoT testing
McCool: could also be external page, as long as can be found
internally
Andrea: would it be nice to have a table?
McCool: trouble is that gets very detailed. let's just add
detailed table of features in implementations TBD
Andrea: the implementation may have additional faetures, that
are not exactly the standard? or the implementation must ONY be
in the standard?
Andrea: for example, mechanism to automatically fetch and
translate the data?
McCool: implementation won't cover those. could be under
proposals
McCool: ... or list it in the Readme, or in your documentation
Kaz: andrea, the main purpose of implemetnation report is to
check on implementability of the specification itself
Kaz: just define the features in spec, and check if implemented
in the actual implementations. Need to cover all the features,
twice.
Kaz: at least more than one implementation
McCool: I just did this to get head around, we will at least
cover the query part.
wot-security issue 196 - Consider security issues in Discovery
<kaz> [13]wot-security issue 196
[13] https://github.com/w3c/wot-security/issues/196
McCool: let's talk about interesting PRs
McCool: one in security, leads to new requirement
McCool: we have PR, that updates the DDS attach
McCool: attack
McCool: however, there were other possible privacy
considerations that we brainstormed
McCool: major blocking issue that came up was around personal
information tracking
McCool: going to be major issue, made a list, actually... it's
even worse when dealing with geoinformation. the mere fact that
a WoT talks with tings in a limited range
McCool: so why see a thing in a certain range, I know the thing
is in the directory, and if in use for a car, then could know
if people are home or not
McCool: similarly, public service, say a parking garage. if
register car with parking garage TD
McCool: I don't own the device and trust the device with my
data. Some guy could track me
McCool: Mitigations in a list
McCool: simply not use registration (don't use WoT discovery)
McCool: we could alternatively encrypt the TD
McCool: problem is how do you find it?
McCool: maybe encrypt all but the DID
McCool: problem with the solution is need to find a reference
for it. Don't know if anyone has patented this or not
McCool: is to use a rotating ID based on code generator.
Encrypt a quantum of time, then the device has a reasonably
acdurate clock
McCool: encrypt it with private key and then update an
encrypted TD with a crypto generated ID
McCool: user wants to access, knows the time. Generate the ID
and seaerch for it
McCool: anyone else who sees the ID, only sees a random string
of characters
McCool: update every few minutes, that's the duration can be
tracked, then goes awa
McCool: raises a requirment: we have to support encrypted TDs
with visible IDs
McCool: it's the encrypted TD part... we have visible IDs taken
care of
McCool: thoughts?
McCool: if encrypted, the query would not work.
McCool: would have to know the ID to find it
Kaz: this is very important as I mentioned during the security
call, Also I've just remembered that the DID WG had disussions
about privacy issues like this during TPAC
Kaz: they use public key encryption, but the DID document
itself might not be encrypted
McCool: right. in our scheme, IDs are used as introductions, so
it might not be encrypted.
McCool: this is just the directory, could still link to it,
link to the ID but only good for a certain (short) length of
the time
McCool: should be stricter about how the link is encrypted
McCool: signed JavaScript object
McCool: should have a flag (boolean) in the meta data
McCool: the diretory needs to store for each TD
McCool: the actual object or a binary blob
McCool: or a ....
McCool: could encode inside another JSON object, but whould
have to enhance the schema
schema
McCool: any comments?
McCool: need implementers to comment, at least two need to
commit to doing it
Andrea: not sure what the use case would be. We could allow
anonymous
Andrea: we would lose all the directory feature set, we can't
use RDF data bases any more, use a data store
McCool: what are the use cases?
McCool: query is for finding things you already know about but
to access what you don't already know
McCool: the case of the own devices, I don't know their current
IP addrss, let's say, so I would publish a current TD
McCool: want to find and check my car
McCool: Already know the ID (rotating code gen)
McCool: Already know the ID (rotating code gen)
McCool: queries are mainly for information I don't already know
farshid: we lose a lot...
farshid: we don't need anything beyond that
McCool: let's capture this discussion in issue
Andrea: make not attribute to these IDs, if in tripple score,
you won't be able to retrieve by ID
McCool: requirement: we need to think about how to support one
feature: retreiival by ID
McCool: wouldn't support notifications, could still get notice
that encrypted TD is updated, but not from properties
Farshid: but you can't track it, another issue
McCool: someone could track, but would need to disable that
McCool: when update ID, you delete the old TD and create a new
one
farshid: so if deletion, closed, ....
McCool: someone could track/follow and guess that the one
that's newly created is the same thing
farshid: correct
McCool: this assumes that the tracker is the person (owner) of
the directory
McCool: owner of the information
McCool: what does it actually offer? car in garage, registers,
with cryptographically generated ID
McCool: now, parking garage knows only that the thing is there,
until it leaves
McCool: but would not associate with a device, type of device
or person
farshid: but you could fuse with other information
farshid: there may be other devices in the home that would be
updated at same time
McCool: so still a fingerprinting risk from fusion with other
information
McCool: look at DHCP logs, granting IPs
Farshid: logs of the proxy or the directory itself
McCool: directory seems communication from a particular IP
address that is updating a new TD
McCool: getting back to DHCP, a new device with known MAC
address. Assume person knows MAC address, they get the IP
address
McCool: that might be one way to track you, but still need to
know the MAC address of the car. so question is do we
completely eliminate risk or just make it really annoying to
track
McCool: similar risk with phones on public networks
McCool: e.g, generating MAC address
farshid: what is the use case where we need to use a public
directory but cannot provide this info ? is this useful? why
not put in private directory?
McCool: two broad use cases: in institutions (factories, smart
cities) and the other is
McCool: publishing public services
McCool: there's also private (personal use). services that user
wants available from remote locations
McCool: e.g., access to car in parking garage from elsewhere
McCool: electric car is charging,and I want to know the status
of charging
farshid: understand, but why not use private registries? no
need to encrypt?
McCool: gets back to mitigation. Don't use WoT for this
McCool: limit WoT to first use case
McCool: make it only user has access keys to the directory. Add
this as an alternative
McCool: Idea here is that register personal devices only to
directories that the user and only the user have access rights
to
McCool: imagine this being hosted in personal home gateway.
Could have a home computer, running a local service. PRovides
directory service.
McCool: go there to find the TD. Car would periodically
register it's IP address
McCool: we'll have to decide if encrypted TDs make sense
McCool: there's implementation effort involved
McCool: last issue would address some use cases, but put more
of an onus on user to have personal directory
<McCool> [14]https://github.com/w3c/wot-security/issues/196
[14] https://github.com/w3c/wot-security/issues/196
McCool: reposting issue in the IRC
<kaz> [15]McCool's comments for wot-security issue 196
[15] https://github.com/w3c/wot-security/issues/196#issuecomment-770961494
PR 107 - Update SPARQL DDoS ed note
McCool: final things: two PRs
McCool: merge this and add to it
<McCool> [16]https://github.com/w3c/wot-discovery/pull/107
[16] https://github.com/w3c/wot-discovery/pull/107
McCool: any objections? none heard so went ahead and merged
PR 112 - Describe the information model
McCool: do another PR on top with other mitigations
McCool: Farshid has a PR for information modeling. At this
point...
Farshid: there's a bunch of changes. Diagram doesn't show in
preview
Andrea: I was reviewing and agree. We should merge the PR and
then work on top of it
McCool: you didn't click on review and accept
McCool: why don't you accept and I will merge after meeting
McCool: we can do delta's against it
comment in next two hours
McCool: out of time!
<FarshidT> Information model PR: [17]https://github.com/w3c/
wot-discovery/pull/112
[17] https://github.com/w3c/wot-discovery/pull/112
Minutes manually created (not a transcript), formatted by
[18]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).
[18] https://w3c.github.io/scribe2/scribedoc.html
Received on Monday, 15 February 2021 12:48:59 UTC