<kaz> scribenick: zkis

prev minutes

<kaz> prev minutes

mccool: is the Scripting API frozen now?

zoltan: yes, last PR has been merged and officially the API is frozen on Wednesday

elena: so security discussions will affect a later version of the API

mccool: are algorithms included?

zoltan: not yet

mccool: we have the metadata issues going on
... any comments of the last meetings minutes?
... looks OK
... any objections to accept the minutes?
... no
... accepted

NDSS

mccool: added more examples of metadata we could include

<kaz> McCool's slides

mccool: addressing states, caching
... firewalls, network policy, including incoming AND outgoing traffic
... discussing services, using cryptocurrency deposits
... endpoint adaptation
... unencrypted headers and encrypted payloads

security metadata requirements

mccool: in the TD there is a lot of discussion about security metadata
... Matthias has shared some examples
... Scripting API issue #91

https://github.com/w3c/wot-scripting-api/issues/91

mccool: provisioning is out of scope
... before exposing a Thing, actually the Thing needs provisioning
... actually the Scripting API affects the state before provisioning
... about the example on how does OCF handle security
... looked at iotivity
... security metadata is kept in specialized resources
... the raml files have class metadata, the resources have instance metadata
... one can access them via introspection

<kaz> IoTivity security architecture

https://wiki.iotivity.org/iotivity_security_architecture_overview

scribe: we have a requirement to expose BOTH patterns
... also, looked through OpenAPI security scheme
... support API keys, Oauth2 etc
... would it be OK just using that?

(link to be inserted)

<kaz> OpenAPI spec ver.3.0.1

mccool: will create issues for these

elena: Matthias suggested to autocomplete security metadata by implementation

mccool: let's start by narrowing focus to operational issues, but now we need to broaden the scope to make usable systems

elena: this is not an operational vs provisioning question
... scripts can create new TDs and Things
... it is part of runtime state

mccool: this includes security provisioning

zoltan: currently the runtime generates the security metadata (the TD .security data)

elena: how does the runtime know what to provision?

mccool: this automatic provisioning does not work with all security deployments

elena: also the granularity is an issue

mccool: on OpenAPI they have a global security conf, then each resource can override it to a local definition
... this will not work with OpenLD
... we need a finer granularity than global
... the TD spec contains an old example for security metadata
... it's an array of objects
... each object containing category (e.g. token), algorithm, authority etc
... context definition is also considered

zoltan: we need more data coming from implementations to determine the right representation of security metadata

mccool: what if we took the OpenAPI security metadata model
... it should be able to represent OCF devices
... OCF tends to hide information inside resources

<kaz> McCool's comment on scripting issue 91

elena: will look into it

<McCool> https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md#securitySchemeObject

mccool: will put a link to an example in the agenda (wiki)
... discussing OpenAPI spec

koster: MQTT and HTTP endpoints will have different security

mccool: different endpoint forms will refer to different link to security configuration
... i.e. define a list of security metadata and link them from the endpoint forms
... discussing how to represent OCF ACLs in the TD

koster: we don't need to do that
... scope the TD

mccool: make protocol bindings for all CoAP, but need to figure out how security works

koster: provisioning state and operational state

mccool: the security section could just say "this is an OCF device"
... the implementation should encapsulate OCF security
... the other way is to open it up, but it's too complex

zoltan: the minimum information is more than "this is an OCF device"; it needs client role, validity period etc

mccool: let's put OCF aside for now, and focus on what generic mechanisms we need to expose in the TD
... we need a strawman specification for this
... Elena would look into the OpenAPI
... Michael McCool work with Zoltan on OCF security adaptation

koster: how does using OpenAPI vocabulary play out
... analyse the different security flows and derive metadata
... OCF has the access management service

mccool: what is the minimum data to bootstrap OCF communication
... will do a basic strawman for next weeks call
... security metadata will be a list of objects referred by id in JSON-LD

<scribe> ACTION: mccool to generate a basic straman description on security metadata

koster: important is to be linkable

mccool: OpenAPI metadata has the "flows" clause

koster: the overall design of OpenAPI seems OK

mccool: will make an md file in the security github
... closing the meeting, any other questions?
... meeting adjourned.