<kaz> scribenick: mlagally

lifecycle

Elena's slides

lifecycle section should live in the main document

McCool: we could not find a lifecycle - only IETF spec has an example. This is a strawman
... maintenance could be intentional or unintentional
... we intentionally assume in security group provisioning has already happened

<yamada> https://rawgit.com/w3c/wot-security/working/index.html#lifecycle-of-a-wot-device

Barry: are you aware of ietf security group? chartered in the last few weeks
... 2 groups: TEEP, SUIT
... SUIT = SW update for IoT
... TEEP = provisioning not limited to IoT
... you have trusted and untrusted parts

McCool: the entire device could be trusted

Dave: you might have trusted services
... our descriptions should cover this

<ryo-k> suit (Software Updates for Internet of Things) - https://datatracker.ietf.org/group/suit/about/

Dave: OMA has merged with IPSO to found OMA Spec Works

<ryo-k> teep (Trusted Execution Environment Provisioning) - https://datatracker.ietf.org/wg/teep/about/

Dave: we should take into account

McCool: we should also work with the IETF groups

<dsr> My point is that the lifecycle also needs to take into account the provisiong of services in gateways and cloud platforms, i.e. provisioning in depth, and not just IoT devices at the edge

<dsr> My second point was the need to encourage coordination on provisioning and management across the many IoT alliances and SDOs. Let’s hope the IETF work helps with that

Elena: presents lifecycle of scripts

<inserted> scribes for today: Lagally, Dave, McCool, Victor

Elena: we have to discuss if script lifecycle is in scope

McCool: 3 cases

wot device with wot runtime

scribe: ocf device with a wot gateway

Dave: this is multi stakeholder

McCool: existing device, where target device has own lifecycle and provisioning
... these are different configurations

Sebastian: same lifecycle for all things?

McCool: perhaps we need multiple models
... different for consumer and industrial
... in industrial, devices may install their own software stack
... having only one model is naive
... we assume only operational state - is this a valid assumption
... script may be installed before operational state

Zoltan: we have 3 lifecycles here (scripting runtime and TD)

McCool: scripting lifecycle is within operational state
... is scripting update in the operational state

Zoltan: this may be outside or may cause a cycle

Elena: we may have a small section on lifecycle

kajimoto: lifecycle diagram - we may need decomissioned state
... ... lifecycle sometimes defined in operational state
... security items may be added by manufacturer

McCool: another state could be "engineering"

Dave: purpose of the diagram? best practice?

McCool: we want to define states to clarify what state we are talking about
... where do the steps take place? depends on the situation

Zoltan: consequence of the diagram?

McCool: clarify scope of standard
... if we can refer to an external standard

Lagally: look at osgi
... look into oracle IOT client documentation for inspiration

Zoltan: OCF lifecycle has a purpose for certification

McCool: an OCF gateway still has to onboard - go through provisioning process - we may need liaison
... technical connection is possible - we may need a bridging at org level

Dave: this is also related to privacy: GDPR in Europe
... we are just defining interfaces
... we want to draw attention to the interfaces

Zoltan: we want to make these connections easy

Kawaguchi: state could be simplified from a SW stack perspective: device is accessible to wot servient, discoverable

Elena: this is just device lifecycle - last slide is about software lifecycle
... please define SW lifecycle

McCool: scripting TF should define this

Zoltan: will discuss later

matthias: this is interwoven with identity management
... we should look at Panasonic model - existing devices

McCool: we also have to worry about other authentication schemes

matthias: dan yesterday raised security question about JSON-LD

McCool: in NDSS we also looked into protecting access, securing against manipulation

Sebastian: how do we handle this topic? make it more convrete? Where do we discuss?

McCool: have not defined TD discovery in the standard
... you could go to a base url and get a TD

Sebastian: where do we discuss this - github issue, f2f?

McCool: we discuss in security TF, but thing directory should be discussed in TD TF

matthias: no additional call - online interim meetings on Architecture

Zoltan: scripting API will refer back to this - we need sth. to be referencable

McCool: identity mgmt. is a lifecycle issue

Zoltan: one or multiple identities of a thing?

McCool: multiple access paths

matthias: multiple TDs from different places, multiple network interfaces, different addresses

Zoltan: in OCF you get an id via ownership

Matthias: different ids from different systems

Zoltan: if you get ocf id and from somewhere else

matthias: WoT shoud have urn mechanism to map uuid, imei etc.

McCool: we need a concrete written proposal - one-pager
... decide in next group meeting where this is discussed

Dave: we should review against best practices for linked data
... group needs to be aware of that

<dsr> see https://www.w3.org/TR/ld-bp/

McCool: we should not just have a string

matthias: @id in TDs mandatory - there were name clashes during the plug fest
... should see how existing things are mapped into this - see Panasonic's plugfest demo

kaz: issues are common with all TFs

McCool: we need a proposal first

kaz: we should also restart architecture work
... lets start with a clear proposal

matthias: I'm updating architecture document anyway - will add a small section

McCool: security could be handled like this too

matthias: architecture needs full lifecycle
... no difference between small device and web server - perhaps just skip the commissioning step

McCool: there are various standards for services: cloud, open fog, ...

matthias: i write a markdown proposal - how to map for existing services
... will integrate initial lifecycle version into architecture document, generalize security TF model
... do longer calls on arch document - want to avoid just another call

Sebastian: would be useful to be more concrete

McCool: diagram needs to be generic enough
... use cases would be more concrete, e.g. consumer + industrial
... existing diagram is svg

Sebastian: Siemens can contribute on industrial use cases

<Discussion on where document can be found>

Barry: please change color of the slide, black on white

Terminology

Matthias: Let's talk about terminology
... could WebThing be an alternative to different terminology?
... corresponds to our abstraction in WoT

Barry: WoT server is an impelementation thing, not an abstraction

McCool: if we assume to get consensus with Mozilla/EVRYTHING, align terminology

Barry: pick something that's easy searchable
... IETF does that

matthias: servient vs. WoT host?

servient was not familar to TPAC participants

scribe: Is WoT host less confusing?
... servient is full SW stack

<brainstorming>

<strawman poll>

<pro's and con's of node vs. servient>

<inserted> [break until 11:10am]

<dsr> scribenick: dsr

Summary of Security Issues for the Scripting API

Elena presenting remotely

She talks us through the main assumptions e.g. security must be transparent for scripts as much as possible

Will we cover security errors? Yes

We assume that the security configuration is handled independently of the scripting API

Diagram for “Flow 1” - in which a script discovers a new device

The script uses network discovery to find a thing

The required security credentials are identifed from the thing description

These credentials are obtained if not already present

The credentials are passed with an action request - the action response returns a result or an error

if the error is due to security, the script can refresh the secutity credentials and retry the action. This may be appropriate when the error indicates that the credentials have expired

McCool: the user may need to do something as part of the process for obtaining the credentials

In one scenario, the credentials are requested when retrieving the thing description

The permissions may be fine grained, e.g. allowing a script to read the status, but not to update it

McCool: the permissions may depend on the user’s role

Daniel: the credentials can declare what a script is permitted to do

Zoltan: this is all encapsulated by the WoT run-time

Matthias: the server sending the thing description cannot always detemine what the client is allowed to do or not ….

The client may be able to identify that the credentials are missing

I like the lazy acquisition of security credentials

Zoltan: when we do discovery, we are doing TD discovery not OCF discovery

MCool: We may want to expose the user’s role as part of the discovery process

Dave: can’t we we indeed handle authentication and authorization as part of the process for fetching a thing description, e.g. returning a bearer token for subsequent use in invoking thing actions etc.

Matthias: if you already had the thing description, you need another means to get the security credentials

Dave: indeed, and you need a means to request the credentials when a security token has expired

Matthias: we should like at how this is handled in RESTful systems

Zoltan: so we need to ensure that the Scripting API is able to report some set of security errors

McCool: we should look for guidance at existing practice

Elena: the general principle is to avoid providing additional information when this isn’t needed

If the information is already present, it can be propagated, but let’s keep things simple

Diagram for “Flow 2” in which a script exposes a new thing

A WoT script wants to specify security restrictions on the thing’s actions and properties

How does the script define and pass the security policy to the run-time

This may involve some protocol specific details, e.g. user id and password for HTTP Basic

Matthias: I would avoid this being set in the script. The run-time knows what security to apply

McCool: the thing description could declare user roles for each property or action, and the run-time could then expose this to an authorization mechanism

Matthias: we want to avoid putting security details in the TD

Zoltan: so are you saying that security policies are handle by a thing?

Matthias: the person who configured a script for exposing a thing, can also set the security policies at the same time

McCool: we can explain this in relation to the lifecycle

Matthias: script author’s shouldn’t need to know about the details of security schemes, and instead just needs to describe his/her intent

Elena: do we agree that we need a way for scripts to pass the intent (e.g. via roles)

Zoltan: no, this could be handled externally as part of the application context

Matthias and Michael talk about the use of identifiers that the run-time can use to map to the specific security mechanisms for the protocols in use

Matthias cites the use of named roles as such identifiers

Zoltan: do we need to standardise these?

McCool: no, they can be passed as opaque strings

Matthias: we should support arrays to allow for multiple roles

Daniel: we would like scripts to be able to run on different platforms

Zoltan: we could use the management interface for managing security policies

Elena: yes, we can manage this out of band and not expose it as part of the scripting API

Matthias: we could support hints …

McCool: we have extensibility through the means to add metadata

The lifecycle is important in that we need to talk about when information is provided and who provides it

<McCool> McCool: summary, we need to work on scripting lifecycle to determine who and when security data is defined.

Scripting API Security Metadata

Zoltan presents …

<McCool> ... normally, private information needs to be provided out of band, and within a script we should (at most) define the policies or roles that particular interactions use.

<McCool> ... these policies or roles should be selected from a list configured by the entity that set up the scripting runtime

We’ve summarised scripting issues in Issue #95

<McCool> ... however, to get consistency, it would be useful if these roles were defined using a common vocabulary. It is suggested that we defined a few such terms but using an extensible mechanism.

<McCool> ... a complex subject, but we can start just with "user" and "admin" and go from there

<McCool> ... it is also noted that security errors *should* be returned by the scripting API, with as much information that is available on the network interface, but no more

<McCool> ... this is based on the observation that a malicious attacker can look at the network traffic anyhow so there's no point making honest users' lives difficult by hiding information

<McCool> ... however, we should define more generic error codes or categories simply for ease of use

Zoltan uses OCF as an example

<McCool> ... there is also the question of defaults... if no policy or role is given, a "default" should be used

<McCool> ... this concept of default may (or may not...) be reflected in the TD... likewise, a "role" may use a SET of security configurations, and this may require a refinement of the current proposal to represent

OCF defines a specific sequence of steps for provisioning with onboarding/ownership transfer, and provisioning of security metadata

<McCool> ... also discussed was how to handle security during discovery, providing different TDs to different users to assist with privacy, and dealing with authorization errors

The WoT run-time needs to comply with the OCF requirements when it comes to exposing WoT things

OCF ownership transfer involves specifying device and owner ids

<McCool> ... points to note: secure delivery of differentiated TDs can be handled in a hierarchical fashion, eg. having a discovery service that needs authentication before it returns a thing

<McCool> ... this may/may not be out of scope; part of the lifecycle discussion

OCF is still refining its provisioning process details

The security metadata is covered by Issue #91

<McCool> ... finally, the scripting API should deal with authentication lazily so that (a) it does not waste time trying to do authentication it does not need (b) it has to do it anyways for certain schemes, eg refreshing expired tokens. SOME things, however, can be checked at startup (eg do I have an appropriate username and password for basic auth) but the more general case requires lazy eval

A WoT client needs to discover the thing, figure out the provisioning service and device info.

The WoT run-time needs to undergo OCF certification

Zoltan: the main use case is to expose OCF devices as WoT things

a secondary use case is to expose WoT things as virtual OCF devices

For the main use case, an application can expose multiple OCF device resources as a WoT thing

Matthias: we could include the full security details in the TD, but probably don’t want to expose all of that to WoT clients

McCool: for gateways, we need liaison with OCF to discuss the details

Zoltan: OCF controlls access to device resources via ACLs

A thing may represent multiple OCF resources

The WoT run-time needs to encapsulate:

- OCF discovery

- Claiming OCF client role

- Requesting access permission + validity period

- Making OCF resource requests (CRUDN)

- Processing replies and requests

McCool: we should use reflection for the run-time to discover the details

Talks about an OCF gateway

Dave: is OCF certification per gateway or per OCF device? In other words would an application hub for the web of things need certification separately for each app that exposes OCF resources.

Matthias talks about OCF work on a bridge and perhaps we can convince them to work with the web of things to simplify that?

McCool: right now OCF is specifiying bridges for each mapping separately

Matthias: I would like to figure out who to talk to the OCF people about their work on bridges

MCool: we need to push them to make this happen

Matthias: OCF won’t certify apps/gateways that bridge OCF devices to other ecosystems

MKoster: at the end of the day, OCF is member driven …

Dave: perhaps we should focus on showing how security can be handled when bridging the web of things to other ecosystems.
... perhaps we (WoT IG/WG) ought to show we know how to address the complications of onboarding and transfer of ownership (e.g. when people move home)

Zoltan: can’t we get some of the Microsoft and other companies to engage with the WoT activities?

Matthias: these companies are putting all of their resources into OCF and claim they don’t have any resources available to also engage with the W3C WoT work

McCool: OCF is making a lot of use of IETF specs, which will help with the WoT security discussion

Zoltan: OCF had a bad experience when merging in AllJoyn

Dave: we need to show that the security challenges can be addressed effectively, even though we won’t be standardising everything - i.e. some aspects are left to WoT application gateway platform providers

<kaz> [lunch until 2pm]

<McCool> test

<kaz> scribenick: McCool

Scripting API Improvement with Simplified TD (Zoltan)

<inserted> Scripting issue 90

Zoltan: issue 90 about errors
... we already talked about security, but there are other categories
... Matthias has requested a list of errors
... depends on algorithm
... all methods can fail for security reasons
... this morning we figured we need a WoT-specific error
... that has more information than the basic Node.js Error object

Matthias: useful to have more information
... there are still arguments to keep it consisitent with normal errors

Zoltan: there is the issue of writing scripts that deal with errors specific to certain protocols
... then not portable
... we need a set of generic error codes
... suggest if you have a list, then add to issue

Matthias: agree don't want protocol-specific codes
... but let's look at RESTful concepts and define a set of generic errors

Dave: want a set of abstract errors

McCool: reporting information not a security issue (if available on the wire), but depending on how we do it, may be a portability issue

Dave: issue is avoiding information that is too specific to a platform

Matthias: for instance, token has expired, etc.

Dave: we can agree that scripts should be portable

McCool: we need a concrete proposal that we can evaluate

Zoltan: have some categories (see the issue) already
... TypeError, NetworkError, SyntaxError, etc.
... there is the issue of the "message"... displaying it or not is up to the application
... there is also a catch-all InternalError with a message

Matthias: should start with existing categories, see how far we get

Zoltan: should we have more than just a message for the SecurityError
... or a symbolic code?

McCool: want symbolic tokens so we can handle certain categories consistently

Matthias: user needs to know how to deal with the error, i.e. they should know when retrying is useful or pointless

Zoltan: suggest people try to capture their opinion on the issue

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

Zoltan: tryed to come up with webIDL to represent web API as a test
... came out a little bit different than the current API
... map-like DOM for instance
... can generate DOM that is consistent with (proposed new) TD

Matthias: after McCool's question, we can use this to build a DOM consistent with JSON-LD 1.1 TD

Zoltan: do we want to expose the security section or not?

Matthias: might be useful for introspection

McCool: what about ID?

Zoltan: will have... point is, will expose everything in the TD

Matthias: there will be an issue for things with @ in front... have to use ["@..."] not .@...
... there are restrictions on identifiers we will have to look into
... some we can map @context to context, but what about @type and type? causes a conflict
... so need to extend the mapping somehow
... don't need to break interactions down into Properties, etc. already broken up

McCool: also possible keyword conflicts

Matthias: but always have the fallback to [] notation

Zoltan: should the mapping be direct?
... can be awkward for scripting

Matthias: changing the names is a problem, 1:1 mapping clearer

McCool: I agree a 1:1 mapping is better

Zoltan: we could just add methods for @types

Matthias: but why? this works fine
... can access everything just with knowledge of the TD
... you just have to know that you have to use [] for @-types

Zoltan: then we should probably not separately define these in the API...

Matthias: if you say we don't specify this, then you just follow the TD implicitly
... we can just tell people what is happening

McCool: just tell people that if it's in the TD it will be in the DOM

Matthias: we can also autogenerate the scripting API DOM spec from the TD spec

Victor: we can take existing tools to generate the spec

Matthias: you said you don't want to track the TD spec...

Victor: can generate webIDL from ontology

Zoltan: could also generate JS object/implementation

Matthias: but we aren't talking about the implementation, but about the spec
... and we already generate a lot of that from a formal model
... so we can do the same thing for the Scripting API

Zoltan: but it's not really necessary since we can do introspection

Matthias: but we need to know where to attach handlers, etc.

McCool: we should distinguish goals and means... goal is scripting API and TD are consistent
... so just figure out how to get there efficiently
... I think that we can just give the rule and don't have to redundantly list everything redundantly

Zoltan: we don't need to specify the structure, already given by the TD

Matthias: but still need attachment points
... eg to add a property
... where do I call this?

Victor: so we should at least have the skeletons for each class?
... but agree it's necessary to add extra entry points

Matthias: we do have to specify skeleton so we can add entry points to it
... need context for function definition
... start doing it and you will hit the problem I'm talking about...

Daniel: I think we can also just try to prototype the generation of the WebIDL
... as a reader, I don't want to jump between two specs, SA and TD

Zoltan: but how do we deal with variable @type syntax

Victor: well, in other cases have similar issues, like $key in JSON-Schema
... so not an unusual problem

McCool: the issue is only that the webIDL generator needs to do the right thing

Matthias: issue is that you want to avoid the @type

Zoltan: can't define @type in webIDL

Matthias: so it's the webIDL spec that is the issue...

Victor: we also have methods like invokeAction...

Matthias: need to know where this goes in the class structure

Victor: the @ keys could be left out of the webIDL spec... and inferred from TD spec
... but we include the "main" classes in the webIDL

Matthias: then we "metadefine" the other things...

Zoltan: that will give bad feedback from the AC

Matthias: it works, so...

McCool: can make ["..."] the main definition, then say the . notation works for things whose identifiers satisfy certain rules

Victor: at least three representations of same JSON-LD object
... advantage of the webIDL is that it gives a canonical representation

Matthias: make this deal
... then we will do another pass that deals with the @types
... make an API, but ignore all @types

Zoltan: but we could infer some of the @type stuff?

Matthias: no... and the spec will be in flux due to the JSON-LD 1.1 transition

Daniel: will take the action to talk to webIDL people about this issue

Zoltan: moving on... examples, how to set a Temperature, etc
... showing use of the different notations

Matthias: note that properties now have get and set

Zoltan: and then there is the observers pattern

Matthias: example does not quite follow the pattern we discussed

Zoltan: in this case, interface implements observable
... alternative is there is an "on" method
... (refering to "temperaturechange" example in issue tracker)
... might need options to pass to subscription
... so using "on" would be nicer if we want to pass options to the subscription
... but we should stick to the known semantics
... also have "on" not only for events but also property change

Matthias: confusion of multiple paradigms

Zoltan: we should probably experiment with writing code with both
... Observable is an ECMAscript proposal, but may not fly
... often used for filtering infinite series, but we aren't doing that

Daniel: what if it does not fly?

Zoltan: then we would have a private definition
... OK... we have a few more issues
... but the intent is to get as close to the TD as possible
... we should track the TD
... starting point for updating the scripting API work

Matthias: if there is an example, we should check that it works

McCool: what about extension keywords?

Zoltan: consuming works, but exposing is a problem
... exposing is a security issues, need to check against known strings

McCool: I would hope it works if the extended key is in the context I include

Victor: this is why framing is important.. know in advance what object should look like
... will remove unknown keys, add prefixes if needed, etc.

Daniel: a good implementation would do that, but... can we enforce it

Zoltan: a risk of injection attacks

McCool: I suggest we break it up... what we can from the scripting API, then separately deal with security risk... and what checks we need to include to avoid problems

Matthias: agree separation of concerns approach is useful
... may have separate validation tools, etc.
... but generally we need to deal with extensions
... maybe have a .validate API call... but in general, we have to figure out how extension points work

Zoltan: ok. regarding other points, will talk to some stakeholders and Javascript purists what makes sense to them
... that all said... mostly we are talking about Consumed things in this spec, need to look at how it works with Exposed things
... also does not really discuss schemas

McCool: but may change anyways if we align with JSON-schema

Daniel: should be easy, simple recursive structure

Matthias: suggest for now do everything except @-types
... we will look into it, later on we will patch in such things
... should look at some other implementations to see how they deal with such exceptions

Kaz: if we have some difficulties with webIDL... can give feedback to Web group

Matthias: proposal is deal with basic things that work, then figure out how to add to the spec how to deal with exceptions
... Daniel will reach out to Toby to see if there already is a solution
... should coordinate with Kaz
... need to find the right person to talk to

Zoltan: Toby is only the latest guy to touch it

Daniel: one question: future
... what are our plans for other languages... is webIDL the right choice
... other languages can use our spec
... first ones that do a non-browser spec will need to do something else

McCool: so why do we bother with webIDL at all?

Matthias: for one thing, it makes adoption in a browser easier
... but we may want an informal guide for other languages

Zoltan: of course you can use the WoT and TDs without scripting at all...

Matthias: maybe move another topic up...
... is an issue about "what is the web"
... read between the lines there that there might be some misunderstanding
... for instance, we need at least some URI scheme
... and example there, we looked into MQTT, a counter-example Mozilla brought up
... of course we need a URI scheme; we know how to do this, but it should be pushed up to a standard
... another example that is counter-example, there are lots of other protocols that are linkable that we probably don't want to use, eg "file://"

Barry: don't even need an RFC
... URI schemes are defined by "expert review"
... so much easier process
... can also just use the Oasis spec

Matthias: also mediaTypes, etc.

Barry: so maybe what we should write is a definition of what protocols are useful with WoT
... and if necessary, guidelines for how to define a URI scheme
... what about Quic, etc.
... a google thing, follow-on to http that runs over UDP
... they will have a URI scheme for it, so that kind of thing should work
... in most cases bad for implementation to worry about protocol...

Matthias: one complication: coap over UDP vs. coap over TCP
... semantics are a little different

Koster: application probably won't have to deal with this...

Matthias: reminder that the URI is just an opaque string...

McCool: Barry, will you take the action to write up a definition of "what it means to be compatible with WoT"?

Barry: sure, I can take a stab at it

Matthias: we should look at the use cases to see what protocols are appropriate to use
... may have different requirements on northbound and southbound interfaces
... may also have proprietary interfaces in various places
... also specialized sub-protocols, eg. over websockets
... may be specialized protocols on both southbound and northbound interfaces
... (CoAP over UDP may or may not be a good example of that)

Koster: how about extensions, cross-exposure between ecosystems, etc

Matthias: may need specific bindings for "proprietary" protocols
... in that case though while it might be accessed from inside a servient, it would not be described with a TD
... could still use a TD...
... reusing mechanisms, but not direct access; feasible vs allowed

Koster: even for generic web interfaces, may want to have a protocol binding to give some details
... there is a question of what is the "natural" mapping
... still want to write it down

Matthias: if you start from the TD, even the defaults define a binding

McCool: what about security? Protcol Binding or TD spec?

Matthias there is also DataSchema

scribe: currently only defined as examples

Matthias: are there another other protocols we should include
... would be a good "check" with our list of requirements
... my understanding it was a proprietary binding
... will discuss tomorrow... but is http

McCool: regarding wot-security working vs master, I will create a PR tonight to get caught up, if the security TF members can be please review ASAP

Matthias: Adjourn

<kaz> [break till 4:20pm]