<scribe> scribenick: kaz

agenda

McCool: object security?
... security scheme to handle

Koster: need to handle key materials
... tell the system to have key materials
... there are many ways to handle object security
... going to handle some mechanism like handshaking

McCool: ok
... (shares the screen)

Koster: would get better understanding
... e.g., pub/sub for security
... maybe close to the end of the year

McCool: (updates the agenda wiki)
... Object security: COSE and OSCORE
... Security consideration sections: Thing Description (McCool), Scripting API (Elena)

Koster: Secure multicast

McCool: status of W3C Note publication
... also previous minutes review

review of previous minutes

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

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

McCool: (starting with Oct-1)
... basically looked at issue 118

issue 118

McCool: this is where object security came up

Koster: JavaScript Object for JOSE as well

McCool: (adds JOSE to today's agenda)
... ok
... let's go through the minutes from Oct 1
... let's add a note here
... object security
... use the title of issue 118

Kaz: ok

[[

Signing and encrypting body of actual responses of interaction pattern endpoints

]]

McCool: and then
... update from online plugfest
... TPAC schedule
... publication plan
... security consideration for TD
... any other corrections?

(none)

McCool: ok let's accept the minutes except adding the title of issue 118

minutes from Sep 10

McCool: prior to plugfest
... adding Kaz to the editors list
... wondering if it's ok
... I'm OK with it
... any thought?
... let's talk about this offline
... PR207
... online plugfest
... best practices document
... btw, any update from Ryo?

Kaz: not yet

McCool: ok
... now the publication is in process
... would accept the minutes
... any objections?

(none)

McCool: accepted

Publication status

Kaz: have been working on TD

McCool: can we publish the note by TPAC?

Kaz: maybe next week
... anyway, I'll start the initial check so that I can get back to you

McCool: ok

Object security

McCool: COSE, JOSE, OSCORE
... need to look into them
... we should address the standards
... how the payload is encoded
... that is a media issue
... should specify media-type for them
... regular media-type and another one for encryption
... do we combine or separate the security scheme

Koster: the way it works
... JS and CBOR or JSON and CBOR, etc.
... similar work done for HTTP
... various ways
... thing to look at is what header option would remain
... regular CoAP processor and payload separately
... options for protected or unprotected
... (refers to rfc8152)
... unicast or not
... having media-type for encoding
... how to specify media-type and sub media-type

McCool: could be sub type
... looking at here for CoAP
... COSE encoding
... these parameters and algorithm used
... section 3.1
... table 2
... need to read through this draft

Koster: don't really know either
... between schema and media-type handling

McCool: kind of secure encoding
... you normally combine the other things
... 5.4 how to encrypt and decrypt for AE algorithm
... Koster, are you volunteering to read through RFC8152?

Koster: yeah

https://tools.ietf.org/html/rfc8152

McCool: do we have to modify TD at all?

Elena: we've indicated security metadata
... but not specified it in detail
... need to go into the detail
... some payload may available even without sign
... not going to be very different
... need new token

McCool: maybe a bit different level of metadata
... simply say we need COSE
... third level indicating the parameter
... intermediate level to mention COSE and JOSE
... COSE with possible algorithm

Koster: would agree with Elena
... need to see the other systems using similar pattern
... we don't have to provide tags
... can go into the draft and see what is needed
... we may need to invent our own protocol

McCool: need common use cases
... for multicasting

Koster: URI and scheme
... IP address to be defined for multicast purposes
... maybe like observing, but not sure

McCool: observing or eventing

Koster: it's listening anyway

McCool: we could look into multicast first
... and think about security for that later

Security consideration sections

<McCool> https://github.com/mmccool/wot-thing-description/blob/security-considerations/index.html.template.html

McCool: I have something and Elena also has something
... changed the paragraph here
... "In many locales, ..."
... TD can contain personally identifiable information
... normative assertion here
... A thing description associated with a personal device SHOULD be treated as if it contained personally identifiable information.

Koster: interesting thing
... move the point on consent
... we're looking at interoperability
... getting beyond that is interesting

McCool: there is a question about when to prepare it

Koster: interesting but out of our scope, isn't it?

McCool: information needed to be accessed
... main point here is what should be normative assertion
... (mentions some example)
... basically we're recommending same category coming from things

Koster: makes a lot of sense

McCool: only edited the last paragraph here
... informative part and normative part
... seems to be OK to merge this proposal?
... need to regenerate the HTML for TD draft

Elena's update

Elena: (shows scriptin API draft on her PC)
... 9. Security and Privacy
... specific recommendations related to WoT runtime implementations

McCool: 3 categories?
... big paragraph could be split into 3 pieces
... sometimes you don't really need isolation
... trouble is that normative assertion needs statement
... particular cases to be described
... you should expand the statement

Elena: ok

Kaz: regarding the first bullet. right?

McCool: yes
... normative assertion needs to be clear

Kaz: maybe safer to use section title with a link to the fragment instead of section number

Elena: ok
... the next one
... (second bullet)
... Therefore the WoT Runtime SHOULD avoid exposing the native device interfaces to the script developers.

McCool: orchestrating with the other devices?
... the first sentence may be a bit misleading
... need right logics
... may want to say
... have to expose the endpoint
... maybe instead
... avoid directly exposing
... maybe we could add some clarification here
... only required functionalities here

Elena: ok
... next bullet
... Therefore, if WoT Runtime supports post-manufacturing provisioning or update of WoT scripts, WoT runtime or any related data, such operations SHOULD be done in a secure fasion.

McCool: we'd mention best practices?
... "in a secure fashion" is important
... we need to include a section on security update

Elena: ok
... next one
... Therefore the WoT runtime SHOULD securely store the provisioned security credentials, guaranteeing their integrity and confidentiality.

Koster: what do you want to test for within an implementation?

McCool: the issue is trust of scripts
... dangerous to use untrusted scripts
... this is intentional feature design
... we should emphasize it

Kaz: which part to be modified?

Elena: additional sentence
... should not expose an API directly access security credentials for WoT scripts

Kaz: will you create a PR for these changes?

Elena: will do

McCool: there is functionality on Thing Directory
... probably we should add an extra point here
... script should not assume ID immutable
... ID may change via transition

Elena: functionality to be preserved?

McCool: yes
... ID can change
... we should go ahead and generate a PR
... should provide a proposal to the Scripting guys and get feedback

Elena: what about testing?

McCool: why don't we have an empty place holder section at the moment?

Elena: ok

McCool: Elena will create a PR to be reviewed
... and I'll update my PR as well

[adjourned]