Meeting minutes
Previous minutes
<kaz> Jan-25
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> wot-thing-description Issue 1015 - Problems translating TDs from JSON-LD 1.1 to RDF and back
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> WoT Discovery implementation page
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> wot-security issue 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> https://
McCool: reposting issue in the IRC
PR 107 - Update SPARQL DDoS ed note
McCool: final things: two PRs
McCool: merge this and add to it
<McCool> https://
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: https://