<scribe> scribenick: kaz

prev minutes

https://www.w3.org/2018/10/15-wot-sec-minutes.html

McCool: don't see any major changes
... talked about best practice doc, TPAC, etc.
... any proposals for changes?

(none)

McCool: accepted

publication status

kaz: will do this week

McCool: the sooner, the better

new possible slot?

McCool: wondering about the time for the security call
... pushed one hour later here in Japan
... probably we should do a doodle to check if there is any better slot
... but why don't we keep this time for the next week

PRs and Issues

McCool: some of them to be merged immediately
... then relatively minor
... and need to discuss CR/PR requirements
... tight timeline now

summary presentation at TPAC

slides

McCool: [Agenda]
... summarized the recent meetings
... [Summary of Recent Work]
... new CoAP scheme
... not yet merged for TD
... [Special Security Meeting (Monday Oct 22)]
... best practices, testing, normative security considerations, additional security schemes, plans for Dec online plugfest
... content type including object security
... penetration testing for online plugfest
... over vpn
... [HTTPS Local]
... proposal for the CG
... [Current HTTPS Security]
... [HTTPS Local Strawman]
... PSK cert using HTTPS
... presented to the CG guys
... the trouble is schemes with browsers
... still possibility but not convinced
... no standard yet
... [HTTP Local: Conclusions]
... not conclusion yet
... [Opens]
... [To Do]
... add additional "context leak" privacy consideration to TD
... complete best practices doc
... functional test
... [Deferred Proposal]
... [Proposed Terminology Change]
... remove "Url" from any scheme parameters that have them
... e.g., authrizationUrl -> authorization
... to make it simpler
... not super critical but nicer
... checked in GH
... URL here on the wiki
... questions?
... if any errata, let me know

new PRs

McCool: cleanup

PR 265

McCool: security cleanup
... security mandatory at the top level
... went it and made it mandatory

changed files

McCool: index.html.template.html
... there is the "MUST" assertion
... and "MAY" assertion here
... also noticed security configuration for binding
... we can't prescribe the behavior of the Thing
... so reworded here

[[

https://github.com/w3c/wot-thing-description/pull/265/files

]]

McCool: both way: MUST and MUST NOT

[[

If a Thing requires a specific access mechanism for a resource, that

MUST accurately reflect the

mechanism MUST be specified in the Thing Description's security scheme configuration

security requirements of the Thing.

for that resource.

</span>

<span class="rfc2119-assertion" id="td-security-no-extras">

If a Thing does not require a specific access mechanism for a resource, that

mechanism MUST NOT be specified in the Thing Description's security scheme configuration

for that resource.

]]

McCool: next

PR 207

McCool: discussion about privacy at TPAC

[[

<li> Deferencing the vocabulary files given in the <code>@context</code>

field can be a privacy risk as such deferences can be used

to infer information about the device especially if domain-specific

vocabularies are used.

To mitigate this, dereferencing of vocabulary files should be

avoided.

<span class="rfc2119-assertion" id="td-vocab-caching">

Vocabulary files SHOULD be cached whenever possible

or (if immutable) built into the device and not derefenced at all,

with the URI in the <code>@context</code> field serving only as

an identifier of the (known) vocabulary.

</span>

]]

McCool: trying to fix this

Lagally: question about that
... obscurity to hide vocabulary?

McCool: someone may access the TD
... they can see the IP address caused by the DNS leak
... may even know what kind of air conditioner
... so dereference may be done only once

Lagally: still thinking about that...
... can understand that attack scenario, though

McCool: if you have new version, you should have new URL
... vocabulary only published just once
... restricting dereferencing is suggestion here
... do you want to issue a comment to this PR 207?
... (add comments to the agenda wiki)
... TD security considerations
... new clause for privacy and @context dereferences
... next 217

PR 217

McCool: clarify "scope" field semantics
... when you login
... you get bearer token
... regular users can get regular ones
... entire addition

Lagally: predefined keyword?

McCool: just string
... Scopes are not identical to roles but are often associated with them
... make comments to this PR if you want
... would like to recommend we talk with the TD guys on Friday and then merge this
... might be access class or something
... and then
... 119

PR 119

McCool: remove Url postfixes
... any objections?
... simply a name change
... last one
... double minded
... overly confused
... not sure who else wants this
... new security definition section at the Thing level
... map of names (@ids) to SecurityScheme objects
... defined names (@ids) can be used later in place of SecurityScheme
... HOWEVER
... it may not be possible to implement
... [Current Security]
... [With Security Definitions]
... security definition, default security scheme, security definition use/override
... a couple technical issues
... possible name conflict
... [Alternative with Security Definitions]
... mixed object here
... digest and something else
... two schemes
... more convenient
... would avoid redundancy
... [Mixed Security Schemes]
... yet another proposal
... oauthScheme, {scheme: basic}
... any comments/questions?

McCool: issues with mixed schemes
... would like to sort this out

Lagally: looks like really complicated...

McCool: would like to avoid this
... override is already very complicated
... would like to talk with Matthias again
... one another option to make it less complicated
... Decomplicated Security Schemes]
... securityDefinitions
... security: [digestScheme]
... most common use case
... this is fine
... one of what we could do
... using this "securityDefinitions" section
... don't want the complication

Elena: lacking the default?

McCool: brainstorming welcome

CR/PR requirements

McCool: we're planning to get a 6-month extension
... the latest is April
... we can't make any normative changes after CR
... a bit concerned about some of the security schemes
... for testing
... we can talk about the best practices
... we can make some of the features "at risk"
... but April is the latest and we need to aim much earlier
... complete all the test cases by March
... some assertions are untestable

Elena: did you get discussion?

McCool: (goes to see the TD draft)
... (sees the definition of "SHOULD")

[[

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there

may exist valid reasons in particular circumstances to ignore a

particular item, but the full implications must be understood and

carefully weighed before choosing a different course.

]]

McCool: the other thing want to close is privacy considerations
... formality of using RDF
... mitigation in TD
... would submit a paper to a workshop
... interesting to have potential vocabulary for threat model
... need to defer until the testing work is done, though
... some work by ISO for IoT
... would like to formalize it
... however, right now testing is the priority

slides presented at TPAC

McCool: wanted to create a prototype for tests
... would like to look at automated test
... regarding security functional testing
... [Test Categories]
... Thing Behavior Testing

<McCool> https://github.com/w3c/wot/blob/master/testing/wot-test-plan-tpac-10-2018.pptx

kaz: note that we need to start with the extracted assertions

Kaz's slides at TPAC

AOB

McCool: anything?

(none)

<scribe> ACTION: mccool to update the security&privacy consideration for td

<scribe> ACTION: elena to update security&privacy consideration for scripting

<scribe> ACTION: kaz to generate a doodle for possible new security time

[adjourned]