W3C home > Mailing lists > Public > public-wot-wg@w3.org > February 2021

[wot-discovery] minutes - 1 February 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Mon, 15 Feb 2021 21:48:53 +0900
Message-ID: <87czx1fqdm.wl-ashimura@w3.org>
To: public-wot-wg@w3.org
available at:

also as text below.

Thanks a lot for taking the minutes, Christine!



      [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


          Andrea_Cimmino, Christian_Glomb, Christine_Perey,
          Cristiano_Aguzzi, David_Ezell, Farshid_Tavakolizadeh,
          Kaz_Ashimura, Kunihiko_Toumura, Michael_McCool,





    1. [4]Previous minutes
    2. [5]Quick updates
    3. [6]Implementations
    4. [7]wot-security issue 196 - Consider security issues in
    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

   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

   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


   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

   McCool: will you implement implementation?


   will not implement SPARQL

   Andrea: we will focus on

   from Siemens: internally, we're discussing and will report next

   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

   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

   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

   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

   McCool: ideally, we need one full implementation for open

   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

   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

   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

   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,

   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


   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

   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

   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

   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

   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

   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

   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

   Farshid: there's a bunch of changes. Diagram doesn't show in

   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/

     [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

This archive was generated by hypermail 2.4.0 : Monday, 15 February 2021 12:48:59 UTC