<kaz> scribenick: zkis
<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
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
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.