agenda

<inserted> scribe: kaz

johannes: shows TF-AP agenda
... would start with the architecture document
... next scripting API
... and joint session with DI, TD and SP
... AP topics include
... finalizing the AP tech landscape
... WG item
... protocol bindings
... plugfest wrap-up

-> https://www.w3.org/WoT/IG/wiki/F2F_meeting_2016,_January,_26th_%E2%80%93_28th,_France,_Nice#TF_AP_Agenda TF-AP agenda

Web of Things Architecture (Kazuo Kajimoto)

kazuo: confusion on the architecture
... and would make it clearer step by step
... (Abstract architecture on TPAC 2015)
... this is Johannes's generated diagram
... this is an abstract model
... (Modified diagram of the basic WoT servient architecture)
... we successfully did the plugfest last night
... trying to clarify the mechanism of the WoT Servient
... Physical API provider for Physical API, etc.
... resource management with Thing Description
... talked with Fujitsu guys, Matsukura-san and Nimura-san
... protocol mapping include the capability of adapter for legacy communication devices
... legacy devices use appropriate interfaces
... Web client communicate with WoT Servient and Web server
... Web server communiate with WoT servient and Web client
... what do you think about this breaking-down

johannes: great to see this improved architecture diagram
... difference with APIs

claes: not sure about the motivation of this trial

kazuo: we had various discussions in Sapporo with related groups, e.g., GPIO, sensors
... WoT servient should have server api, client api and physical api
... that is good input
... and would update the abstract architecture diagram for that

johannes: we have two APIs for network connection (server/client)
... and also should have physical APIs
... the question is whether the mechanism should be also standardized or not

louay: good to clarify what is the client API, etc.

dape: good to see this

johannes: for the architecture, good to see what is in it

kazuo: (Simple example for WoT)
... this is a simple example
... controlling WoT devices from browsers
... browser can call the client API (within the browser)
... and send commands to the Web server part of the WoT servient
... ((A) WoT servient on device (WoT device))
... device is a WoT servient, directly interprets the WoT APIs
... the WoT servient on the right side is a device (=WoT device)
... ((B) WoT servient on Smartphone)
... within the smartphone (=two boxes on the left side)
... browser and WoT servient co-exist
... another possibility is another smartphone on the right side

ph: UI on browser for the right side picture?
... what is the purpose of the right side picture?

kazuo: the left side picture is regarding the GotAPI model of OMA

kaz: so the WoT servient within the right picture includes UI capability of a Web browser

johannes: left side picture implies CoAP interface between the browser part and the WoT servient part

kazuo: right
... (C) simple model
... ((D) WoT Servient on Cloud Server)
... application platform on the Cloud Server
... legacy devices are connected to the Hub
... this is the model used for the plugfest demo by panasonic yesterday
... commands sent from the browser through the platform cloud server
... defining this level of modules would be useful to develop actual systems

ari: should we discuss protocol bindings, etc., as well?

johannes: what protocol is used and mapped?

ari: how do you expose the functionality
... some minimal set?

johannes: understood
... need mapping with the resource model
... the conclusion here should include that the architecture should have resource management layer as well

RESOLUTION: we update the architecture with Kajimoto-san's proposal

johannes: we can use this for the WG charter deriverables as well

<scribe> ACTION: kazuo to send the slides to the group and update the f2f wiki with the link [recorded in http://www.w3.org/2016/01/27-wot-ap-minutes.html#action01]

<trackbot> Created ACTION-26 - Send the slides to the group and update the f2f wiki with the link [on Kazuo Kajimoto - due 2016-02-03].

johannes: anything else?

ph: motivation of the improvement should be also recorded

johannes: we need to keep in mind about the structure of the document

ph: also the motivation

johannes: suggestion on the document structure on Github?
... or wiki?

kazuo: would start with wiki

claes: could you put the link to the document?

kazuo: will do

WoT scripting APIs (Louay Bassbouss)

louay: shows the Github repo

-> https://github.com/w3c/wot/blob/master/TF-AP/thing-api/thing-api-webidl.md Github repo for Thing API

<inserted> louay: Interface ThingRequest

louay: not only discovery but look up
... the goal is getting access regardless of concrete approaches
... the most important is ThingFilter
... collect what is in my mind

johannes: having two basic interfaces. right?

louay: yes
... next Interface Thing
... more or less compromise for Thing Description
... getting ID of each object
... something to discuss with the TF-TD
... 'reachable' is some feature to see if you can get response from the device
... other functionalities like callAction
... setProperty, getProperty
... if you want to subscribe events
... we have three functionalities, addListener, removeListener, and remove AllListeners
... you can subscibe any APIs even if it doesn't exist
... and will get an error
... we need to think about that

johannes: how to handle actions?
... explicitly define the event?

louay: several possibilities

johannes: when you implement a servient on the server side
... and somebody calls an action

louay: there are different APIs, server API, client API and physical API

johannes: different class to expose the functionality?
... agree we start with separate the interfaces
... but in some cases we need to use some of them at once

claes: you don't know the name of the attributes
... which are the available actions, events, etc.

louay: e.g., I have some BLE device
... how to get attribute names?
... e.g., humidity

claes: generic mechanism to see in Thing Description?

louay: if you're a developer who use this API
... the developer should know about what feature is available
... if we have accessory which support humidity and temperature
... we need something to know the list of capability

claes: standardizing this would be very difficult

maxime: how to interact with each other
... surprised if there is no mechanism to see

louay: the interface is already there

johannes: mechanism to access property is missing
... you can dynamically access properties

louay: you can get a list of actions, but can't tell which action means what
... if you discover media server from DLNA, you can tell what it means, though
... the same happens here
... the semantics of the thing is lost

johannes: how to know what action corresponds to what properties
... how to handle every thing type

louay: next, Interface ThingEvent

johannes: let's see the examples
... how to know the value of the component has changed?

louay: using the event name?

johannes: can use the physical API to change the actual value
... have to have event name
... interaction pattern

louay: the listener has 'eventName'
... you can tell which is event
... (show "Example Discover Things nearby")
... if you have different set of properties and actions, you can put them

johannes: the name must be unique
... same name for the action and the property

louay: three functions
... when the call is done, we get the event

johannes: invoke or call actions
... we can start with separate interfaces for the first sketch

louay: same abstraction is used for homekit
... really hidden for applications
... there is no actions
... only properties

johannes: ok
... the both interfaces are separated now

nimura: other thing API to access the actual device?

louay: for homekit you can access the devices within the range
... there is a solution for homekit
... maybe you need to get access for thing object

nimura: can we have a common API from application viewpoint?

louay: more or less depends on the underlying mechanism
... not reachable if not connected or not at home, etc.

johannes: given the time, would suggest we conclude that
... we want to have the interface on the server side and the client side
... separate discovery of thing
... we keep your wording on the github

kaz: would be great if you could add a diagram about your example on the Github repo :)

louay: ok

dape: will create an issue on the uniqueness of the name: property name, action name

johannes: anything else?

(nothing)

johannes: wraps-up the session
... discussions on the architecture and the scripting APIs
... thanks for your contributions
... will have lunch from now
... will resume at 13:30 for the joint meeting with TF-SP here at room 153

[ lunch ]

<tidoust> scribenick: tidoust

Security and impacts on APIs and protocols

Oliver: The basic architecture is that we have a Thing, connected to a Servient component. On the other end, we have a caller component, and APIs for each one of them.
... Encryption is not an architecture problem. If it's HTTP, then TLS should be used. DTLS in peer-to-peer.
... The main problem from my perspective is at the Servient level.
... It's something that runs 24/7 and that receives requests from various callers.
... The Thing is a private request. The Servient exposes it at a public-facing interface.
... So anyone, including the Mafia can send requests to the Servient.
... There needs to be some secret sauce in there, some bits that are compliant with the protocol you're using and that protects the Servient component.
... Are we on the same page?

Francois: Encryption often involves authentication, e.g. in TLS with certificates.

Oliver: Of course, as soon as you call for authorization, we have to make sure that you have some notion of trust.
... Number one requirements is authorization, as mentioned by Carsten this morning.
... Number two is entity authentication.
... And then number three is actual encryption.
... In that order.
... Number three can be viewed as message authentication, which invovles the encryption.
... Number three is not a priority, could be number 7 in practice.
... My understanding at the Servient level is that we have e.g. a PUT method that proxies a request to the actual thing.
... The enforcement (whether you agree to receive a PUT method and whether you're going to execute it) needs to be close to the resource.
... The farther away you are from the resource, the worse the protection will be.

Claes: If we say that encryption is not a problem because we have DTLS for instance, cannot we say that authorization is something we have today, e.g. through OAuth?
... We have standards there as well.

Oliver: First, I love OAuth. However, OAuth does not give you everything. The security token is mentioned in OAuth, but not its actual content.
... It's up to e.g. the Google engineer to do the work.
... You can think about different kinds of token.
... This is nothing that the IETF is doing.
... OAuth helps but only gives you half of what you need.

Claes: So the OAuth specification itself does not provide enough to address resilience issues?

Oliver: No. What I'm saying is that the security abstraction is not defined.
... Also OAuth is a domain-based solution which I believe is not enough for cross-domaing authentication.
... Again, I'm not complaining about OAuth. It is a wonderful approach, it is just not doing all the tricks that we need to address.
... The domain model in OAuth works as follows: there is something called the "Resource Server", the "Item of Interest" and the "Authorization Service".
... The spec just tells you how the client calls the Authorization Service (RFC6749), how to the client calls the Resource Service (RFC6750)
... and the Registration endpoint (in another RFC)
... It does not tell you what composes the authorization token.
... To have a chance to get the Item of Interest, you have to have the security token.
... This is what the Authorization Service gives you, but for that you need a client ID and client secret, which you obtain from the registration endpoint.
... Not knowing what composes the security token is OK for a single domain (e.g. GMail).
... In this case, the token is created and consumed by the same domain. The security token can be opaque for the client.

Claes: Your problem is that there is something missing so that the Authorization Service and the Resource Server can understand each other?

Oliver: Right. It may not be an issue, just a point to understand. I don't believe that there is one-token-fits-all solution.
... Not being defined gives you flexibility.
... You have a logical model and a physical model. If you implement all the authorization logic in the Resource Server, you cannot easily change the production of tokens. It should be external to the Resource Server.
... That's a logical separation.

Claes: I'm just considering the problem with OAuth, whether we need to handle that.
... Do you have suggestions for solutions?

Oliver: I'm not trying to get rid of OAuth.
... Just pointing out facts.

Johannes: Wouldn't it be something where we specify a minimal set of properties for this object?

Oliver: Yes. I think there needs to be extension points.

Daniel: If you have several resources, how do you propagate authorizations to the different endpoints that need to know about it.

Oliver: That's the next step. The client is not really constrained in the OAuth case. Assuming that it can speak HTTP, it can speak OAuth. If you have a very constrained device that only speaks CoAP, then you need to invent a helper component on the right-hand side of the diagram I have on the blackboard.
... This is what the IETF ACE group is doing.
... The original OAuth community does not really scale down to connected things.
... ACE introduces a new component, initially called AM, now CAS (Client Authorization Server).
... The IoT client itself needs to present the security token. The CAS component knows how to get it.
... Back to the interaction, when you get a 401 response, you don't necessarily understand what you need to do, where to go to get the authorization token.
... The information as to what needs to be done is in human readable form in the body of the response.
... However, there is a very strong binding between how the IoT client needs to react and the text instructions.

Johannes: What would be the final takeaway? First, description of the security token? Second, no standardized way to describe why an authorization failed? Third where would the validation of the authorization takes place in our architecture?

Oliver: OAuth does not have yet a concrete proposal on how the different components talk to each other.
... The solution is not yet there.
... You can of course do shortcuts.
... e.g. I only care about my security protocols.

Claes: You mentioned the ACE group. What should be fixed in W3C when it comes to authorization?

Oliver: The ACE group, I believe, will come up with a proposal, but there are at version 0.1 for the time being, so it will take a bit of time. I'm not suggesting that we should step in.
... We may want to provide feedback from a W3C perspective.
... From a protocol perspective, there are things that are not yet covered, the role for us is to express our expectations.
... The next thing I'm suggesting to do is work on annotations to express when a light is private or public at the Resource Server level.
... On the Client side, there needs to be security anchors for the APIs

Johannes: Wrapping up, some impact on the Server API regarding on how to protect access resources, on the Client API regarding on how to access tokens.
... on the Protocol mapping regarding how to get the token, and on the granularity of protection.

Oliver: I have a list of requirements in my mind. I can draft an initial list.

Johannes: The important takeaway is to write the outcomes of the session on the Wiki. One track related to the Security and Privacy status overall, and the second track on more specific impacts on our architecture.

[End of breakout]

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: i/johannes:/topic: agenda
Succeeded: i/louay:/louay: Interface ThingRequest
Succeeded: s/object/device/
Succeeded: s/create/will create/
Succeeded: s/scripting/the scripting/
Succeeded: s/?1/Daniel/
Succeeded: i/johannes: shows TF-AP agenda/scribe: kaz
Found Scribe: kaz
Inferring ScribeNick: kaz
WARNING: No scribe lines found matching previous ScribeNick pattern: <tidoust> ...
Found ScribeNick: tidoust
ScribeNicks: tidoust, kaz
Present: Kaz_Ashimura(W3C) Johanees_Hund(Siemens) Daniel_Peintner(Siemens) Louay_Bassbouss(Fraunhofer_FOKUS) Claes_Nilsson(Sony_Mobile) Toru_Kawaguchi(Panasonic) Kazuo_Kajimoto(Panasonic) Maxime_Lefrancois(EMSE) Hitoshi_Hayakawa(Hitachi) Ari_Keranen(Ericsson) Yuki_Matsuda(UNI) Philipp_Hoschka(W3C) Shinji_Hoshino(ACCESS) Kazuaki_Nimura(Fujitsu) Ryuichi_Matsukura(Fujitsu) Dominique_Hazael-Massieux(W3C) Francois_Daoust(W3C) Oliver_Pfaff(Siemens) Joerg_Heuer(Siemens)
Got date from IRC log name: 27 Jan 2016
Guessing minutes URL: http://www.w3.org/2016/01/27-wot-ap-minutes.html
People with action items: kazuo