<kaz> scribenick: kaz

Privacy

McCool: has some chat with Elena about PR 103

-> https://github.com/w3c/wot-security/pull/103 PR 103 (Privacy mitigation)

Previous minutes

-> https://www.w3.org/2018/06/04-wot-sec-minutes.html previous minutes

McCool: security metadata PR for TD (PR #144) has been merged
... ready for plugfest

Kaz: there were the following actions to be included

<scribe> ACTION: [ONGOING] mccool to talk with security guys about testing/validation timeline

<scribe> ACTION: [ONGOING] mccool to work on issue 70 (Require Not Exposing Immutable Hardware Identifiers?)

<scribe> ACTION: [ONGOING] mjkoster/elena to review examples in the security spec

<scribe> ACTION: [ONGOING] mccool to write a short proposal on what security tools to use for the next plugfest

McCool: put those actions in the previous minutes

Kaz: ok
... will add another action for PR144 from the previous call (which is done for today)

McCool: ok

(minutes accepted with those changes)

Privacy threat mitigation

McCool: kind of discussed at the beginning of this call

<scribe> scribenick: mjkoster

McCool: any comments?

Elena: what is ID?

<kaz> TD draft

McCool: it is a uuid which will not collide with other UUID instances
... there is an RFC on UUID we should cite
... we can't exclude unique identifiers so we need to protect them from tracking
... the TD itself can also be tracked
... so there are 2 options; protect the entire TD and allow the ID to be mutable

Elena: would it be regenerated on boot? will the ID change on a device

McCool: there are different ways to get a UUID, like timestamp, domain name, random, etc.
... there may not be a DNS identifier on a constrained device, so would need to use a UUID
... maybe the ID would be randomized on reboot
... but there may also be a permanent ID
... what are the recommendations?

<kaz> Koster: OCF uses UUID-based permanent ID

<kaz> McCool: any particular citation?

<McCool> https://tools.ietf.org/html/rfc4122

<kaz> ... RFC 4122 fine for citing?

Koster: OCF has a permanent ID and session-oriented ID

<McCool> https://www.itu.int/ITU-T/studygroups/com17/oid/X.667-E.pdf (mm refers to an ITU-T standard as well)

Koster: a session is == the onboard tenure of a device before the ID changes and it needs re-something

McCool: can we get references?

Elena: an onboard session may last for a long time, like a year

McCool: if it can be protected, it may not be a problem
... there may be a risk, but there is a mitigation in being able to change the ID

Elena: it may be difficult to change all of the identifiers

McCool: periodic refresh may be able to be automated

<McCool> https://w3c.github.io/wot-thing-description/#thing

<McCool> btw unique ids are *mandatory* for TDs

Elena: please look for the references

McCool: other points to the discussion on privacy?
... google iot privacy recommendations

PlugFest

McCool: plugfest preparation document for security
... recommending TLS + one form of auth from a choice of [bearer token, basic, digest]
... also want to do TD validation with security checks and warnings
... still to do pen testing investigation
... google pentesting
... also pen test
... any other thoughts or discussion on plugfest?
... one way to require security is to require an online version which is forced to also require security
... this will also facilitate the online continuous testing

F2F agenda for Bundang

McCool: security metadata
... combined session with scription
... security validation and testing
... the discussion needs to evolve to a presentation to start discussion
... best known practices for security, but it would rapidly become obsolete

<kaz> Bundang f2f wiki

Koster: but it would be good to drive things forward as there has not been much movement in IoT security to date

McCool: we need to be able to change the document over time, maybe an IG document

Kaz: WG note should be fine to produce

McCool: we may need to update it forever

Kaz: how to maintain security spec is being discussed
... there are many possibilities
... maybe a security group to address
... we need to figure out extension vocabularies

Issues and PR review

McCool: issue #101

<scribe> ... closed

<kaz> issue 101

McCool: issue #98 form based auth

<kaz> issue 98

McCool: need URI templates for this to work in order to pass query parameters

Koster: is it just a binding template?

McCool: also need another scheme "form" that authorizes at a URL with a template

Koster: need to figure out the design pattern

McCool: maybe a form as part of a security binding
... maybe we would need an action to define how to authorize
... making notes in issue #98

Koster: maybe iotschema vocabulary for security and login type concepts

McCool: issue #96 closed
... issue #81 and #77 done but maybe not ready yet, will review again
... done and wrapup for today
... trying to finish TD validation and move on this week
... aob?

Kaz: testing call?

McCool: didn't reschedule formally yet

Kaz: Ege has asked about the call

McCool: cancel the testing call today and do the combined call this week
... adjourn