<kaz> scribenick: dezell
<kaz> May-11 minutes
McCool: (creates a new issue for OAuth2 flow)
<kaz> [typo fixed]
<McCool> https://github.com/w3c/wot-security/issues/173 - insert in May 11 minutes
<kaz> ACTION: kaz to add a link to issue 173 on OAuth2 to the May-11 minutes
RESOLUTION: accept minutes for 11 May - but add link to issue #173.
McCool: closing PR #171 without merging.
<McCool> https://pr-preview.s3.amazonaws.com/w3c/wot-security/172/4166672...OliverPfaff:39d8e12.html
Review section 7.
Focus on section 7.4 end-to-end security.
<McCool> https://pr-preview.s3.amazonaws.com/OliverPfaff/wot-security/pull/172.html
Oliver: people tend to think that
end-to-end security is absolute.
... it's not a fixed thing. You need to know assets, how
they're used, and what technologies you use to protect
them.
... so "end-to-end" might be different things to different
people.
... examples in this section call on classical security
practices - CMS, TLS, IPSec, MACsec
McCool: we should really add
references to each of these technologies.
... also, the technologies are used at different levels of the
stack.
... we need some indication of what that level is for each.
Oliver: Second part addresses the
data itself.
... if you have to do your own security scheme at the data
level, classical offerings are second best.
McCool: we've been looking at
signing TDs, and maybe using DIDs.
... we should look at using JWS for signing.
Oliver: for signing objects, the
first plan is to use JSON specific encrypted/signed data.
... there has to be a good reason for expressing an "alien"
syntax.
McCool: in "discovery" we were talking about directory structures, and I think we created an issue somewhere, maybe in "security," #166.
<McCool> https://github.com/w3c/wot-security/issues/166
McCool: (reference 7.4 in the
Security document)
... if we have some LD proofs, getting the TD from the
directory should leave proof that it hasn't been tampered.
Clerley: a big part is a
mechanism for protecting the keys. Should we give specific
consideration to keys.
... My experience is that this is a hard problem.
McCool: let's hold that and
create a new topic.
... I think this comment should be linked to directories.
Oliver: XML Signature had 3 ways
of expressing signatures.
... JWS is less complex. Enveloped is not supported
directly.
... detatched, enveloping, and enveloped.
(end digression into "signing")
McCool: any objections to merging #174?
(hearing none...)
(Note: merge shows everything changed - must try to remedy offline.)
McCool: so Clerley asked if key
protection should be in scope.
... question is "what is standardizable."
Clerley: not so much management, but protection.
Elena: you'll have to use OS provided means to do the protection, so it's hard to predict.
McCool: some systems do a good job of strong key protections, where you'll never handle the keys.
Clerley: are there assumptions that only known OSs will be used?
McCool: we have security and
privacy guidelines.
... we don't force certain things.
... we could say "you should" in certain cases.
... we also have best practices.
... this last is "if you were building a device today, do
this."
<McCool> https://github.com/w3c/wot-security-best-practices/blob/master/index.html
McCool: recommend you review best practices and add suggestions.
Clerley: OK.
David: important to tell people what to worry about, even if we don't give a prescription.
McCool: agreed. Making Clerley
and assignee for this issue.
... issue #170.
<McCool> https://github.com/w3c/wot-security/issues/170
McCool: we can make informative recommendations.
McCool: we need to come up with a
short list of topics.
... part of the meeting should be driven by issues.
(adding topics to Wiki)
Kaz: we will have some presentations tomorrow at the AC meeting, and it might be a good opportunity.
McCool: I'm trying to figure out
how to have a constructive discussion.
... next meeting let's add 4 slides for this topic.
McCool: we should discuss further in the architecture call.
Adjourned.