The Web of Things (WoT) Interest Group (IG) is collecting concepts and technologies to enable discovery and interoperability of Internet of Things (IoT) services on a worldwide basis. The discussions of the IG already shaped preliminary WoT building blocks: the WoT Thing Description (TD), a Scripting API, Protocol Bindings, discovery mechanisms, and cross-cutting security & privacy considerations. The current practices related to WoT building blocks were also prototyped and tested in so-called PlugFests. The documentation of these WoT building blocks, however, are usually scattered across multiple drafts, meeting minutes, wiki entries, slides, and even verbal agreements. Thus, this document tries to provide an overall snapshot of the current practices of the WoT interest group in a single location. While this document is not a technical specification, it aims at helping implementers to get a overview of the WoT building blocks. Furthermore, it includes reports from past PlugFests and follow-up discussions, which explain the rational behind the current practices.

This document is an intermediary release of the current practices that were used at the Santa Clara 2017 PlugFest of the Web of Things Interest Group. The IG believes that most of the recommendations listed in this document will be refined and addressed after each new PlugFest event, where individual and task force proposals are evaluated and tested. In particular, this series of notes will document the current status of discussions within the IG for implementers of the drafted building blocks.

Introduction

The Web of Things (WoT) Interest Group (IG) provides a forum for technical discussions on the role of Web technologies for a combination of the Internet of Things (IoT) with the Web of data. Apart from the Use Cases and Requirements and Technology Landscape deliverables, the IG is also working on promising concepts and prototypical building blocks. It turned out challenging for implementers to follow the current practices resulting from the IG discussions. This is, however, very important for the mission of the PlugFests, where the current practices should be tested and evaluated through prototypes. Moreover, it is hard for newcomers to quickly get a picture of the IG activities and intermediary results. Thus, this document shall provide a snapshot that represents the current practices of the WoT IG. It preserves the latest consensus of the discussions among the Members as well as the results of the the PlugFests. Note that this document is not a technical specification, but more a working document for implementors of the prototypical WoT building blocks.

Vision

The central idea of WoT is that Things can describe their capabilities and metadata in a machine-understandable format: the WoT Thing Description (TD), which is rooted in RDF. The TD can be served by a Thing itself or hosted elsewhere on the Web. This way, a TD can also be retrofitted on existing devices, and thereby complement existing IoT platforms and standards with rich metadata to enable interoperability across platforms. WoT also supports flexible Protocol Bindings that enable the mapping of a semantically described Thing interaction to different protocols, since each domain has different requirements here. Finally, WoT envisions to provide a common runtime environment for IoT-related apps. Sensors and actuators can be improved by installing better data processing algorithms or by adding completely new features through software. With a common runtime environment, aggregation apps can be instantiated in the cloud and then relocated to local hubs, or even directly onto a powerful Thing, to meet certain quality of service requirements.

How to get started

Terminology

This document uses the following terms defined elsewhere.

CoAP
Constrained Application Protocol [[!RFC7252]]
JSON-LD
A JSON document that is augmented with support for Linked Data by providing an @context property with a defining URI [[!JSON-LD]]
JWT
JSON Web Token [[!RFC7519]]
Protocol Binding
A mapping from operations on the WoT resource model to specific operations of a protocol (see )
RDF
The Resource Description Framework (RDF) of the Semantic Web [[!rdf11-concepts]]
Repository
A registry for TDs that provides a Web interface to register TDs and look them up, for intance using SPARQL queries
Scripting API
Programming interface that allows scripts to discover Things through a Discovery API, issue requests through a Client API, provide resources through a Server API, and access directly attached hardware through a Physical API (see )
Servient
The addressable application endpoint of a Thing that makes it interactive by providing a WoT Interface and means to execute application logic
SPARQL
A query language for semantic data
Thing
The abstract concept of a physical entity that can either be a real-world artifact, such as a device, or a virtual entity that represents physicality, such as a room or group of devices
Thing Description
An RDF document (currently serialized in JSON-LD by default) that contains semantic and functional descriptions of a Thing (see for details)
WoT Interface
Resource-oriented Web interface (often called "Web API") that allows access to servients over the network using different Protocol Bindings (see )

Concepts & Building Blocks

Things in the WoT architecture are represented by so-called servients, which are usually hosted directly on the physical thing. Yet servients can also represent virtual Things, for instance a collection of Things (e.g., all lights in a room) or a WoT gateway for legacy devices (e.g., a Bluetooth device connected to a smartphone). In this latter case, servients are hosted anywhere, a smartphone, local gateway, or the cloud. Servients communicate with each other through the so-called WoT Interface, a Web API that follows the recommendations of the WoT IG. Servients can be in client role (i.e., they only consume other Things), server role (i.e., they only provide capabilities), or both (i.e., they use other Things, but also provide capabilities).

Things are implemented by a servient and communicate through their WoT Interface.

Each Thing is described by a WoT Thing Description (TD). The TD must be acquired to use and interact with the Thing, since it describes the semantics of a Thing as well as its WoT Interface. Usually, Things directly provide their own TD, but the TD can also be hosted externally if there is not enough space on the device or when a WoT-compatible legacy device is retrofitted with a TD. To ease discovery, TDs can be registered with a well-known TD repository, where Things of interest can be queried, for instance using SPARQL.

Servients can also host a runtime environment that allows application logic to be implemented in portable scripts.

The application logic of a Thing (or technically a servient) can be implemented natively, for instance in the device firmware, which is expected to be common for very resource-constrained Things. Following the patterns in the Web, however, application logic should also be provided by scripts. This is supported through a scripting runtime environment—similar to the Web browser—that may be provided by a servient. Portability of such scripts is ensured through a common Scripting API that allows access to discovery, the client and server functionality of the servient, and the hardware physically attached to the servient.

In the following, the technical building blocks for the Web of Things are discussed on more detail.

WoT Interface

A WoT Interface is a Web interface (often called "Web API") that is describable by a WoT Thing Description (TD). That means it provides Web resources that implement the interaction patterns of Properties, Actions, and Events. Furthermore, it must support the mediaTypes and security mechanisms defined in the TD. The WoT Interface is used for the communication between servients using networking protocols (as opposed to the Scripting API, which is used for the communication between a script and the runtime environment within a servient.

Resource Model and URIs

Based on the fundamentals of the Web, the interactions with a Thing are modeled as Web resources, which are identified and addressable through URIs. The first part of a URI is the scheme, which identifies the protocol used, e.g., http://..., ftp://..., or rtp://.... Depending on the application requirements, the Web already allows to switch between protocols, for instance when an HTML page retrieved over HTTP has a link to a stream provided over the Real-Time Transport Protocol (RTP). Similarly, Thing interactions can be available over different or even multiple protocols, indicated by the scheme of the URIs. See later for more details on the addressing of interaction resources.

Protocol Bindings

We currently have an implicit mapping from WoT interaction patterns to specific protocol operations such as REST or BLE methods. The WoT architecture is not limited to the Protocol Bindings listed here. These simply represent the commonly used protocols at the recent PlugFests.

The default interaction with Properties is read. When they are marked writable, they can also be written. Actions must support invocation, which results in the creation of a handle resource (e.g., a sub-resource of the Action resource). Yet Actions may also support a read to list running or queued taks as links. The linked handle resources may exhibit further interactions such as writing an update of the task parameters or cancellation. Events offer a subscribe interaction, which results in the creation of a handle resource similar to tasks.

Depending on the interaction, a payload may be optional or required. For details see .

HTTP Binding

  • Property
    • Read: GET
    • Write: PUT
  • Action
    • Invoke: POST
    • Update task: PUT (on handle resource)
    • Cancel task: DELETE (on handle resource)
  • Event
    • Subscribe: POST + (Long-)Polling/Chunking/Streaming of returned handle resource
    • Update subscription: PUT (on handle resource)
    • Cancel subscription: DELETE (on handle resource)

CoAP Binding

  • Property
    • Read: GET
    • Write: PUT
  • Action
    • Invoke: POST
    • Update task: PUT (on handle resource)
    • Cancel task: DELETE (on handle resource)
  • Event
    • Subscribe: POST + Observe of returned handle resource
    • Update subscription: PUT (on handle resource)
    • Cancel subscription: DELETE (on handle resource)
      Note that CoAP Observe has cancellation support. This would represent pausing the subscription, where the configuration is preserved for the Event and can be resumed through a new GET + Observe.

MQTT Binding

@TODO Help needed by MQTT implementers

BLE Binding

@TODO Help needed by BLE implementers

WebSockets Binding

@TODO Help needed by WebSockets implementers

Security Mechanisms

The security mechanisms in this section describe how to to establish the authorization and the authentication of WoT interactions for the following components:

  • A Resource server (RS) responding to requests via HTTP or CoAP
  • A Client (C) sending requests via HTTP or CoAP

Note that adding security is regarded to be optional. Moreover, the mechanisms currently described provide basic protection of the interactions. Doing so is intentional to offer a low entry-barrier to encourage many security-enabled PlugFest implementations. For that purpose it is fully intentional to take various shortcuts. For production use additional considerations and additional security mechanisms/checks will typically be required.

The architectural security model adopted from IETF ACE define also the following components:

  • An Authorization Manager (AM) representing multiple clients
  • An Authorization Server (AS) representing multiple resource servers

For a security-enabled PlugFest implementation Request Authorization and Caller Authentication is considered to be the primary goal while Message Authentication and Encryption represents a subordinate security goal for now.

We would like to point out that the technical details are the same as in previous PlugFests (see HowTo description from Nice PlugFest). That said, this is also the reason that some identifiers and names relate to Nice (e.g., NicePlugfestRS or NicePlugfestAS).

Simple Request Authorization and Caller Authentication

The goal is to authorize requests and (implicitly) authenticate callers by means of bearer security token (JWT, see [[!RFC7519]]) with minimal contents.

For the protection of high-value resources, PoP respectively HoK models may be required instead of bearer tokens.

The following security communication practices provide details for PlugFests and might be moved to a decicated section given that it does not fall anymore into the scope of this section, namely "Concepts & Building Blocks".

Communications via HTTP

Resource Server (RS) Security over HTTP

  • Configuration of the RS component:
    • RS id: NicePlugfestRS
    • AS issuer name: NicePlugfestAS
    • AS public signature verification key for ES256 use the following JWK object
  • Registration

    Skipped for RSs that support ES256 for now.

  • Operation when receiving a HTTP request at a protected endpoint
    1. Check if the request contains an Authorization header. Respond with a 401 error if not
    2. Check if the request contains an Authorization: Bearer-header with non-null/empty contents. Respond with a 401 error if not
    3. Check if the value of the Authorization: Bearer-header is a JWT object. Respond with a 401 error if not
    4. Check if the JWT object is signed. Respond with a 401 error if not
    5. Check if the signature of the JWT object is valid. This is to be checked with AS public signature verification key (see above). Respond with a 401 error if invalid
    6. Check the contents of the JWT object
      • Check if the value of "iss" is NicePlugfestAS. Respond with a 401 error if not
      • Check if the value of "aud" is NicePlugfestRS. Respond with a 401 error if not
    7. Accept the request as well as "sub" as the originator of the request and process it as usual

For more background see [[!RFC6750]] (HTTP Bearer tokens), [[!RFC7519]] (JWT), and [[!RFC7517]] (JWK).
For JWT libraries in various programming languages see http://jwt.io.

Client (C) Security over HTTP

  • Registration

    Registration is done according [[!RFC7591]] and described in the following.

    Create a HTTP request with JSON request content as in the following prototype and send it via TLS to the AM.

    For the PlugFest use URL: https://ec2-54-154-59-218.eu-west-1.compute.amazonaws.com/iam-services/0.1/oidc/am/register.
    Note that the registration endpoint is unprotected for the purpose of the Plugfest.

    Request
    POST /iam-services/0.1/oidc/am/register HTTP/1.1

    Request headers
    Host: ec2-54-154-59-218.eu-west-1.compute.amazonaws.com
    Content-Type: application/json
    Accept: application/json

    Request body
    {
    "client_name": "yourClientName",
    "grant_types": ["client_credentials"]
    }

    Naming convention: replace all values prefixed "your" with your value i.e. use any string of your choice instead "yourClientName"

    Response

    Check that you get a 201 Created response and extract the value of client_id (this value is called <c_id> in the following) and the value of client_secret (called <c_secret> in the following) from the JSON response body. A response body prototype is:

    Store <c_id> and <c_secret> for use during the token acquisition.

  • Token Acquisition

    Create a HTTP request as in the following prototype and send it via TLS to the AM.

    For the PlugFest use URL: https://ec2-54-154-59-218.eu-west-1.compute.amazonaws.com/iam-services/0.1/oidc/am/token.
    Note that the registration endpoint is unprotected for the purpose of the Plugfest.

    Request
    POST /iam-services/0.1/oidc/am/token HTTP/1.1

    Request headers
    Host: ec2-54-154-59-218.eu-west-1.compute.amazonaws.com
    Content-Type: application/x-www-form-urlencoded
    Accept: application/json
    Authorization: Basic Base64(<c_id>:<c_secret>)

    Request body
    grant_type=client_credentials

    Response

    Check that you get a 200 OK response and extract the value of the access_token member from the JSON response body. A response body prototype is:

    Decode the value of the access_token value. This provides a JWT structure. Optionally validate it (see above for JWT validation hints). Extract the value of the as_token member in the JWT payload. This value is called <as_token> in the following.

  • Operation when requesting HTTP to a protected endpoint
    • Attach an Authorization: Bearer <as_token> header to HTTP requests to RS.
Communications via CoAP

Resource Server (RS) Security over CoAP

  • Configuration of the RS component

    Same as for HTTP communications. See above.

  • Registration

    Same as for HTTP communications. See above

  • Operation when receiving a CoAP request at a protected endpoint
    1. Check if the request contains a CoAP option 65000 with non-null/empty contents. Respond with a 4.01 error if not
    2. Check if the value of the CoAP option 65000 content is Bearer <jwt_token> with a non-null/empty <jwt_token>. Respond with a 4.01 error if not
    3. Check if the JWT object is signed. Respond with a 4.01 error if not
    4. Check if the signature of the JWT object is valid. This is to be checked with AS public signature verification key (see above). Respond with a 4.01 error if invalid
    5. Check the contents of the JWT object
      • Check if the value of "iss" is NicePlugfestAS. Respond with a 4.01 error if not
      • Check if the value of "aud" is NicePlugfestRS. Respond with a 4.01 error if not
    6. Accept the request as well as "sub" as the originator of the request and process it as usual

Client (C) Security over CoAP

  • Registration

    Same as for HTTP communications. See above.

  • Token Acquisition

    Same as for HTTP communications. See above.

  • Operation when requesting CoAP to a protected endpoint
    • Attach a Bearer <as_token> as value of the CoAP option 65000 to CoAP requests to RS.

Advanced Request Authorization and Caller Authentication

The Authorization Manager (AM) and Authorization Server (AS) components also support a more advanced way of request authorization that supplies a JWT bearer security token with actual access control information in style of AIF (draft-bormann-core-ace-aif-03).

@TODO integrate advanced level of request authorization and caller authentication

Message Authentication and Encryption

Message authentication and encryption is done by means of TLS (for HTTP) and DTLS (for CoAP).

@TODO add adequate information how message authentication and encryption is to be done

Thing Description

The WoT Thing Description (TD) provides the semantic metadata of a Thing as well as a functional description of its WoT Interface. For this, it relies on the Resource Description Framework (RDF) [[!rdf11-concepts]] as an underlying data model. For now, [[!JSON-LD]] is used as the default TD serialization format. The WoT IG defined a minimal vocabulary to express the capabilities of a Thing in terms of different interaction patterns: Properties, Actions, and Events. In addition, the TD provides metadata for the different communication bindings (e.g., HTTP, CoAP, etc.), mediaTypes (e.g., "application/json", "application/exi", etc.), and security policies (authentication, authorization, etc.). gives an overview of the relevant content defined in a TD.

Concepts of the Thing Description (TD)

The subsequent subsection will give a brief introduction to the TD as JSON-LD samples. This is followed by more detailed explainations of the TD elements, a number of more complex TD examples, and finally the considerations for use in production.

Quick Start: TD Samples

In the following, we introduce three minimal TD samples to show the prospects of the W3C Thing Descriptions. Example 1 shows a simple TD that describes a temperature Thing with the name MyTemperatureThing.

                        {
                          "@context": ["http://w3c.github.io/wot/w3c-wot-td-context.jsonld"],
                          "@type": "Thing",
                          "name": "MyTemperatureThing",
                          "interactions": [
                            {
                              "@type": ["Property"],
                              "name": "temperature",
                              "outputData": {"valueType": { "type": "number" }},
                              "writable": false,
                              "links": [{
                                "href" : "coap://mytemp.example.com:5683/temp",
                                "mediaType": "application/json"
                                }]
                            }
                          ]
                        }
					

Based on this content, we know there exists one Property interaction resource with the name temperature. In addition, information is provided such as that this Property is accessable over the CoAP protocol with a GET method (see CoAP protocol binding here) at coap://mytemp.example.com:5683/temp (announced within the endoind structure by the href kye), which will return a number (TD type system) inside a JSON structure (JSON as payload format is announced by the mediaType field).

In practice, a Thing provides further details about what kind of Thing it is and what the interactions mean. This additional information is the semantic context of the Thing. JSON-LD provides a means to extend a TD with an external (semantic) context, which allows to reuse existing models, thereby enhancing semantic interoperability. Through a context, the meaningless strings turn into semantically defined terms that are part of a linkable vocabulary. Example 2 shows the integration of the sensor namespace and the resulting semantic enrichment of the temperature Property with an additional entry within the @type and unit assignment.

						{
						"@context": ["http://w3c.github.io/wot/w3c-wot-td-context.jsonld",
									 { "sensor": "http://example.org/sensors#" }
									],
						  "@type": "Thing",
						  "name": "MyTemperatureThing",
						  "interactions": [
						    {
						      "@type": ["Property",
"sensor:Temperature"
], "name": "temperature",
"sensor:unit": "sensor:Celsius",
"outputData": {"valueType": { "type": "number" }}, "writable": false, "links": [{ "href" : "coap://mytemp.example.com:5683/", "mediaType": "application/json" }] } ] }

Example 3 shows a more advanced TD reflecting an LED Thing that supports multiple protocols (CoAP and HTTP), mediaTypes (JSON and EXI), and security policies (it requires a JWT for interaction). This example also shows the definition of the endpoint information in a global manner. More precisely, a global defined base URI is valid for defined interaction resources. Indivdualiziation of the URI's resource is done by the href key within the interaction definitions.

						{
							"@context": [
								"http://w3c.github.io/wot/w3c-wot-td-context.jsonld",
								{ "actuator": "http://example.org/actuator#" }
							],
							"@type": "Thing",
							"name": "MyLEDThing",
							"base": "coap://myled.example.com:5683/",
							"security": {
									"cat": "token:jwt",
									"alg": "HS256",
									"as": "https://authority-issuing.example.org"
								},
							"interactions": [
								{
									"@type": ["Property","actuator:onOffStatus"],
									"name": "status",
									"outputData": {"valueType": { "type": "boolean" }},
									"writable": true,
									"links": [{
										"href" : "pwr", 
										"mediaType": "application/exi" 
									},
									{
										"href" : "http://mytemp.example.com:8080/status",
										"mediaType": "application/json"
									}]
								},
								{
									"@type": ["Action","actuator:fadeIn"],
									"name": "fadeIn",
									"inputData": {
										"valueType": { "type": "integer" },
										"actuator:unit": "actuator:ms"
									},
									"links": [{
										"href" : "in", 
										"mediaType": "application/exi" 
									},
									{
										"href" : "http://mytemp.example.com:8080/in",
										"mediaType": "application/json"
									}]									
								},
								{
									"@type": ["Action","actuator:fadeOut"],
									"name": "fadeOut",
									"inputData": {
										"valueType": { "type": "integer" },
										"actuator:unit": "actuator:ms"
									},
									"links": [{
										"href" : "out", 
										"mediaType": "application/exi" 
									},
									{
										"href" : "http://mytemp.example.com:8080/out",
										"mediaType": "application/json"
									}]									
								},
								{
									"@type": ["Event","actuator:alert"],
									"name": "criticalCondition",
									"outputData": {"valueType": { "type": "string" }},
									"links": [{
						              "href" : "ev",
						              "mediaType": "application/exi"
						            }]	
								}
							]
						}
					

Based on this TD, one is able to know that a JSON Web Token (JWT) is required to interact with the resources of the Thing. They are issued by https://authority-issuing.example.org and signed using HMAC SHA-256 (HS256). The status of the Thing can be requested using a CoAP GET on coap://myled.example.com:5683/pwr (base URI from the global scope endpoint definition plus the href) or an HTTP GET on http://mything.example.com:8080/myled/status. It can also modified using a PUT on the respective URIs, since Property is writable. The Actions can be invoked through a POST to the resources fadeIn (/in for CoAP and /myled/in for HTTP) and fadeOut (/out for CoAP and /myled/out for HTTP) with an integer value in milliseconds serialized as JSON or EXI. Please note, all this protocol binding assumptions are explained here. MyLEDThing also serves for the CoAP protocol an Event called criticalCondition, which enables clients to be informed about problems (enabled by the CoAP GET with the Observe option to coap://myled.example.com:5683/ev). This event sample also shows the local scope definition of the endpoint which overwrite global defined endpoint information. Such a mechanism allows to restrict or expand endpoint oppertunities of indivdual interaction resources.

Semantic Metadata

TD Context

JSON-LD is a serialization format that adds a semantic layer on top of the JSON specification: the terms that appear in a JSON document should be associated with uniquely identified concepts from shared vocabularies. This principle is part of a set of practices to publish data on the Web called Linked Data, where concepts are usually identified with URIs and originate from RDF vocabularies.

The association between terms and concept URIs has to be declared in preamble of the JSON document with the keyword @context. The expected value for @context can be of different kinds. A first option is to use a JSON object where keys are terms and values are concepts URIs, e.g.:

								{
								  "@context": {
								    "name": "http://www.w3c.org/wot/td#name",
										"uris": "http://www.w3c.org/wot/td#associatedUri",
										"unit": "http://purl.oclc.org/NET/ssnx/qu/qu-rec20#unit",
										"Thing": "http://www.w3c.org/wot/td#Thing",
								    ...
									}
								}
							
It is also possible to declare namespaces in the context instead of terms. In the example above, three of the four URIs have the same prefix: http://www.w3c.org/wot/td#. This common part could be given a short name, refered to as a namespace (as in XML). URIs could then be shortened by concatenating namespace with : and a local name (anywhere in the JSON-LD document). E.g.:
								{
								  "@context": {
										"wot": "http://www.w3c.org/wot/td#",
								    "name": "wot:name",
										"uris": "wot:associatedUri",
										"unit": "http://purl.oclc.org/NET/ssnx/qu/qu-rec20#unit",
										"Thing": "wot:Thing",
								    ...
									}
								}
							

For the sake of reusability, it is also possible to define an external JSON-LD context and simply give its URI as value of @context. All JSON terms that are defined in the present document have been put in an external document, available at http://w3c.github.io/wot/w3c-wot-td-context.jsonld. It is highly recommended (but not mandatory) to include this standard context in a Thing Description. A basic Thing Description would contain the following declaration:

								{
								  "@context": "http://w3c.github.io/wot/w3c-wot-td-context.jsonld",
									...
								}
							

A third option is to declare an array, in case a single document involves several contexts. Array elements are either objects or strings, as explained above. This option proves relevant if one wants to extend the existing TD context without modifying it. For instance:

								{
								  "@context": ["http://w3c.github.io/wot/w3c-wot-td-context.jsonld",
								               {"sensor": "http://example.org/sensors#"}],
								  ...
								}
							
Section provides a more concrete example on that topic.

Security

Example 2: Context for the TD
{
							...
							"security": {"cat":"token:jwt", "alg":"HS256", "as":"https://authority-issuing.org"},
							...
						}
The (optional) security field can be used to provide access metadata (self-contained) information of the Thing for securely transmitting information via all its resources. Also see Section .

Here as a example, JSON Web Token (JWT) type is assigned (cat), the corresponding hashing algorithm "HS256" (alg), and issuing authority of the security token (as).

Thing Metadata

A TD will provide some generic metadata vocabularies that can be used, e.g., to assign a name or what kind of protocols does a servient support.

							{
								...
							  "name": "MyLED",
							  "base": "coap://myled.example.com:5683/"
								...
							}
						

There are three mandatory and one optional (shown as italic text in JSON snippet) vocabulary terms defined within metadata:

  • name: Name of the Thing (string-based)
  • base: [optional] Define base URI that is valid for all defined local interaction resources
  • security: [optional] The security field can be used to provide access metadata (self-contained) information of the Thing for securely transmitting information via all its resources. Also see Section . Above, the security field is used to announce that JSON Web Token (JWT) has to be used to interact with the resources of the Thing. Thereby, type is assigned by the cat field, the corresponding hashing algorithm "HS256" by the alg field, and the issuing authority of the security token by the as field.

Note: Besides these pre-defined terms in the TD context, additional characteristics can be added such as product ID, firmware version, location, etc. These terms should then appear in the context of the Thing (as detailed in ).

Note on URI Resolution

A servient can be associated to more than one URI (e.g., in case it supports several protocols). The same way, links in Properties, Actions, or Events can be defined as an array instead of a single string. The IETF recommendation for URI resolution [[!RFC3986]] does note fully cover that case. This section is an attempt to specify how to resolve URIs in a Thing Description document.

  • A Thing Description can define one or more base URI in the uris field. If only one URI is defined, the JSON value is a string. If more than one URI is defined, the JSON value is a string array.
  • Each string from the uris JSON value must be an absolute URI that is interpreted as a protocol-specific base URI identified through the URI scheme.
  • Properties, Actions, and Events can define one or more hrefs values. If the JSON value of uris is a string, that of hrefs must also be a string. If uris is a string array, the JSON value of hrefs can be either a string or a string array.
  • If the JSON value of hrefs is a string, the algorithm of [[!RFC3986]] can be applied to any of the base URIs available. Note that hrefs can also contain an absolute URI pointing to an external resource or a different protocol for this specific interaction.
  • If the JSON value of hrefs is a string array, it must contain as many elements as that of uris. The resolution algorithm of [[!RFC3986]] must then be applied index-wise. Again, individual array elements may contain an absolute URI.

Interaction Patterns

Property

The array field properties is used to reflect one or more interactions of the Property pattern. Property provides readable and/or writeable data that can be static (e.g., supported mode, rated output voltage, etc.) or dynamic (e.g., current fill level of water, minimum recorded temperature, etc.).

							{
								...
							 "interactions": [
							    {
							      "@type": ["Property"],
							      "name": "temperature",
							      "outputData": {"valueType": { "type": "number" }},
							      "writable": false,
							      "links": [{
							      	"href" : "coap://mytemp.example.com:5683/temp",
							      	"mediaType": "application/json"
							      }],
							      "stability": 10
							    },
								...
							}
						

There are four mandatory and three optional (italic in JSON sample) terms defined for the Property pattern:

  • @type: RDF type of the interaction that defines the semantics through a Linked Data vocabulary (Property is the default value)
  • name: Name of the Property, which can also be used for simple semantic disambiguation
  • outputData: Which data type is associated with this Property (see for details)
  • writable: Is this Property writable (true/false)
  • links: Local link definitions (as array) with href and mediaType definition
  • stability: [optional] Expected period in ms the Property value is expected not to change (>0=estimated period; 0=irregular change; -1=static value)
  • security: [optional] Access metadata (self-contained) for protecting this Property and securely transmitting information. Compared to the security field that can be found in the Thing metadata, this field here can be used to apply specific security requirements that is only valid for this resource.

Absolute URIs in hrefs or endoint can point to an external resource that is not hosted on the Thing directly. This can be useful to link data into the context of the Thing, for which there is not enough space in the device itself. Absolute URIs could also point to a proxy or gateway that allows access to legacy systems that might belong to a Thing that does not have the capability to translate by itself (but provides other, WoT-compatible resources). This mechanism is also interesting for virtual Things that combine the services of multiple other Things (e.g., a room lighting servient that has Properties for each individual light, while these linked Properties are hosted directly on those lights).

If the property is writable (writable=true), then the Property accepts the same format(s) as input as described for its output.

The stability field provides a hint for caching and polling. This value should also be included in the cache control information of protocols, e.g., the Cache-Control header field of HTTP or Max-Age option of CoAP.

Action

The Action interaction pattern targets changes or processes on a Thing that take a certain time to complete (i.e., actions cannot be applied instantaneously like property writes). Examples include an LED fade in, moving a robot, brewing a cup of coffee, etc. Usually, ongoing Actions are modelled as Task resources, which are created when an Action invocation is received by the Thing.

Within the TD, the Actions of a Thing are declared in the JSON array actions.

							{
								...
							  "interactions": [
							    {
							      "@type": ["Action", "actuator:fadeIn"],
							      "name": "fadeIn",
							      "inputData": {
							        "valueType": { "type": "integer" },
							        "actuator:unit": "actuator:ms"
							      },
							      "links": [{
							      	"href" : "coap://mytemp.example.com:5683/in",
							      	"mediaType": "application/json"
							      }]
							    }
							  ]
								...
							}
						

There are one mandatory and four optional terms defined within the Action type:

  • @type: RDF type of the interaction that defines the semantics through a Linked Data vocabulary (Action is the default entry)
  • name: Name of the Action, which can also be used for simple semantic disambiguation
  • inputData: [optional] The call parameters associated with this Action. A valueType field defines the concrete type (see for details). Additional characteristics can be given through terms defined in the context metadata (e.g., unit ms from an actuator vocabulary) similar to Properties).
  • outputData: [optional] Which data is resulting from this Action (same condition as inputData above)
  • links: Local link definitions (as array) with href and mediaType definition
  • security: [optional] Access metadata (self-contained) for protecting this Action and securely transmitting information.

The hypertext reference (href) field works similar to Properties.

Usually, invoking an Action results in a response that indicates a new (sub-)resource, where the started Task can be monitored and also controlled: Updating this Task resource may allow for modification of the process (e.g., when it is still queued and not started yet, but also during runtime if the process supports that). Deleting this Task resource may allow for cancellation of the Action execution. Once the Task completes, the (sub-)resource may be removed by the server; or it is marked as completed, but kept for traceability. It is also possible that calling an action produces a so-called action result that is not manifested in any temporary resource nor other changes to the server (e.g., a conversion process or dry run).

Event

The Event interaction pattern enables a mechanism to be notified by a Thing on a certain condition. While some protocols such as CoAP can provide such a mechanism natively, others do not. Furthermore, Events might need a specific configuration that requires data sent and stored on the Thing in a standard way. There are are two mandatory and two optional terms defined within the Event pattern:

							{
								...
							  "interactions": [
							    {
							      "@type": ["Event", "actuator:alert"],
							      "name": "criticalCondition",
							      "outputData": {"valueType": { "type": "string" }},
							      "links": [{
							      	"href" : "coap://mytemp.example.com:5683/ev",
							      	"mediaType": "application/json"
							      }]
							    }
							  ]
								...
							}
						
  • @type: [optional] RDF type of the interaction that defines the semantics through a Linked Data vocabulary
  • name: Name of the Event, which can also be used for simple semantic disambiguation
  • links: Local link definitions (as array) with href and mediaType definition
  • outputData: [optional] Configuration data associated with this Event. This field works similar to the one of the Action pattern.
  • security: [optional] Access metadata (self-contained) for protecting this Event and securely transmitting information.

So far, the concept of events has not been evaluated yet during the PlugFests. Thus, there has been little discussion and no common practice has emerged. The following text is a proposal to trigger discussion.

The interaction with Events works similar to Actions with the difference that no side effects are intended on the Thing. A client issues a request to the URI of an Event, which may include a payload that represents the configuration data for the Event mechanism. Upon reception, the Thing creates a (sub-)resource, which serves as a handle for the Event subscription. It can be monitored to receive notifications: an HTTP client would need to poll this resource, while a CoAP client would simply observe it. Technically, multiple clients could use the subscription resource created by another client when they are interested in the same Event configuration. The Event configuration can also be updated and ultimatively deleted to clean up internal notification hooks.

Type System

All of the three interaction types Property, Action, and Event can specify the type of the value acceptable as an input or expected as an output of the interaction. JSON schema [[!draft-zyp-json-schema-04]] [[!draft-fge-json-schema-validation-00]] provides a standard way to describe the structure and datatypes of data, and we use JSON schema as the notation for value types of the interaction types.

Note: In the embodiment of type system described in this section, JSON schema is used as an abstract description system for structured data. JSON schema is something that is already out there being used and well-known, therefore gives us a chance to get started quickly to experiment with type system idea for further contemplation. Through discussion, the following points have been noted as feedback for improvements.

  • JSON schema specification was designed for JSON, therefore, may not be an optimal solution as an encoding-neutral description system.
  • JSON schema does not provide a way to associate data elements with citations or semantic concepts defined elsewhere.
  • JSON schema is relatively verbose.
Note that there is an idea (Proposal for the type system for Things) that was incubated independently and was put forward to the IG for consideration.

For Property and Event interaction types, each property or event can specify its value type using valueType with JSON schema definition as its content. The following is an example value type definition. In the example, temperature property and criticalCondition event are defined as number and string, respectively.

						{
							...
						  "properties": [
						    {
									...
						      "name": "temperature",
						      "valueType": { "type": "number" },
									...
						    }
						  ]
							...
						  "events": [
						    {
									...
						      "name": "criticalCondition",
						      "valueType": { "type": "string" },
									...
						    }
						  ]
							...
						}
					

Similarly, for Action interaction type, each action can specify its input and/or output value type using valueType with JSON schema definition as its content. The following is an example value type definition for an action. In the example, fadeIn action is defined to have inputData of type number and outputData of type boolean.

						{
							...
						  "actions": [
						    {
									...
						      "name": "fadeIn",
						      "inputData": {
						        "valueType": { "type": "number" },
						        "actuator:unit": "actuator:ms"
						      },
						      "outputData": {
						        "valueType": { "type": "boolean" },
						      },
									...
						    }
						  ]
							...
						}
					

Simple Data

With value types described by means of JSON schema, serialization of data exchanged between servients is straightforward when it is in JSON format.

Consider the following valueType definition which defines the value to be a number within the value range of [ 0 ... 255 ].

							"valueType": { 
								"type": "number",
								"minimum": 0,
								"maximum": 255,
							}
						

When the number being exchanged is 123, data serialization in JSON format will look like the following.

							{ "value": 123 }
						

The same data (i.e. a number of 123) will look like the following when the data is exchanged in XML.

								<number>123</number>
						

At the time of this writing, some JSON parsers and serializers seem to have problems with value-only literals. Also, whether a single literal such as "hello" is itself a valid JSON instance depends on the JSON specification (RFC vs. ECMA). Therefore, wrapping the value with a top-level object seems to be prudent.

Structured Data

In the previous section, we used an example valueType definition consisting of a single number.

Since we are using JSON schema to describe valueType, it is also possible to define value types that have more than one literal value. JSON provides two distinct constructs to define a structure that can have multiple literal values. One is JSON object, and the other is JSON array.

JSON Object

The following is an example valueType definition that defines the value to be an object that consists of two named literals id (of type integer) and name (of type string) where id is required to be present.

								"valueType": {
								    "type": "object",
								    "properties": {
								        "id": {
								            "type": "integer"
								        },
								        "name": {
								            "type": "string"
								        }
								    },
								    "required": ["id"]
								}
							

When the id number and the name string values being exchanged are 12345 and "Web of Things", data serialization in JSON format will look like the following.

								{
									"value": {
										"id": 12345,
										"name": "Web of Things"
									}
								}
							

The above data will look the following when the data is exchanged in XML.

									<object>
										<id>
											<number>12345</number>
										</id>
										<name>
											<string>Web of Things</string>
										</name>
									</object>
							

Using the TD model and JSON Schema in a single document may lead to a name conflict: properties is used both to declare Properties of the Thing and expected keys in a JSON object. Depending on the use case, if a serialization of the Thing Description in RDF is required, the valueType definition should be processed with an additional JSON-LD context that overrides the mapping for properties (see [[!JSON-LD]], Advanced Context Usage).

JSON Array

The following is an example valueType definition that defines the value to be an array that consists of exactly three number literals with each value within the range of [ 0 ... 255 ].

								"valueType": {
								    "type": "array",
								    "items": {
								        "type" : "number",
								        "minimum": 0,
								        "maximum": 255
								    },
								    "minItems" : 3,
								    "maxItems" : 3
								}
							

When the numbers being exchanged are 208, 32 and 144, data serialization in JSON format will look like the following.

								{
									"value": [
										208,
										32,
										144
									]
								}
							

The above data will look the following when the data is exchanged in XML.

									<array>
										<number>208</number>
										<number>32</number>
										<number>144</number>
									</array>
							

Mapping to XML Schema

In the previous section, examples showed what those data whose valueType are described using JSON schema look like when serialized to XML in parallel to corresponding JSON serializations.

This section describes how JSON schema definitions can be mapped to XML schema definitions by using the same examples. Given JSON schema definitions, providing the mapping to XML schema allows XML tools to directly validate serialized XML data, for example.

The XML structure is based on EXI4JSON [[!exi-for-json]]. The structure works uniformly well for both schema-less and schema-informed use cases.

A complete "JSON Schema" to "XML Schema" mapping needs to be defined.

JSON Object Definition to XML Schema

Shown below is the JSON schema object definition used as the valueType in Section JSON Object. The object consists of two named literals id (of type integer) and name (of type string) where id is required to be present.

							{
							    "type": "object",
							    "properties": {
							        "id": {
							            "type": "integer"
							        },
							        "name": {
							            "type": "string"
							        }
							    },
							    "required": ["id"]
							}
						

When the object is anonymous (i.e. it is the root, or participates in an array definition), the above object definition transforms to the following XML Schema element definition.

							<xs:element name="object" xmlns:xs="http://www.w3.org/2001/XMLSchema">
							    <xs:complexType>
							        <xs:all>
							            <xs:element name="id">
							                <xs:complexType>
							                  <xs:sequence>
							                    <xs:element name="integer" type="xs:integer" />
							                  </xs:sequence>
							                </xs:complexType>
							            </xs:element>
							            <xs:element name="name" minOccurs="0">
							                <xs:complexType>
							                  <xs:sequence>
							                    <xs:element name="string" type="xs:string" />
							                  </xs:sequence>
							                </xs:complexType>
							            </xs:element>
							        </xs:all>
							    </xs:complexType>
							</xs:element>
							

JSON schema object does NOT define any order. Therefore, in order to capture the constraints of JSON schema object, we need to use xsd:all constructs instead of xsd:sequence.

Otherwise (i.e. the object is a member of another object definition, thus has a name), the object definition transforms to the following XML schema element definition. Note __name should be replaced by the actual name of the object.

								<xs:element name="__name" xmlns:xs="http://www.w3.org/2001/XMLSchema">
								    <xs:complexType>
								        <xs:sequence>
								            <xs:element name="object">
								                <xs:complexType>
								                    <xs:all>
								                        <xs:element name="id">
								                            <xs:complexType>
								                              <xs:sequence>
								                                <xs:element name="integer" type="xs:integer" />
								                              </xs:sequence>
								                            </xs:complexType>
								                        </xs:element>
								                        <xs:element name="name" minOccurs="0">
								                            <xs:complexType>
								                              <xs:sequence>
								                                <xs:element name="string" type="xs:string" />
								                              </xs:sequence>
								                            </xs:complexType>
								                        </xs:element>
								                    </xs:all>
								                </xs:complexType>
								            </xs:element>
								        </xs:sequence>
								    </xs:complexType>
								</xs:element>
							
JSON Array Definition to XML Schema

Shown below is the JSON schema array definition used as the valueType in Section JSON Array. The array consists of exactly three number literals with each value within the value range of [ 0 ... 255 ].

								{
								    "type": "array",
								    "items": {
								        "type" : "number"
								        "minimum": 0,
								        "maximum": 255,
								    },
								    "minItems" : 3,
								    "maxItems" : 3
								}
							

When the array is anonymous (i.e. it is the root, or participates in another array definition), the above array definition transforms to the following XML Schema element definition.

								<xs:element name="array" xmlns:xs="http://www.w3.org/2001/XMLSchema">
								    <xs:complexType>
								        <xs:sequence>
								            <xs:element name="double" minOccurs="3" maxOccurs="3">
								                <xs:simpleType name="minInclusive">
								                    <xs:restriction base="xs:double">
								                        <xs:minInclusive value="0"/>
								                        <xs:maxInclusive value="255"/>
								                    </xs:restriction>
								                </xs:simpleType>
								            </xs:element>
								        </xs:sequence>
								    </xs:complexType>
								</xs:element>
							

Otherwise (i.e. the array is a member of an object definition, thus has a name), the array definition transforms to the following XML schema element definition. Note __name should be replaced by the actual name of the array.

								<xs:element name="__name" xmlns:xs="http://www.w3.org/2001/XMLSchema">
								    <xs:complexType>
								        <xs:sequence>
								            <xs:element name="array">
								                <xs:complexType>
								                    <xs:sequence>
								                        <xs:element name="double" minOccurs="3" maxOccurs="3" >
								                            <xs:simpleType name="minInclusive">
								                                <xs:restriction base="xs:double">
								                                    <xs:minInclusive value="0"/>
								                                    <xs:maxInclusive value="255"/>
								                                </xs:restriction>
								                            </xs:simpleType>
								                        </xs:element>
								                    </xs:sequence>
								                </xs:complexType>
								            </xs:element>
								        </xs:sequence>
								    </xs:complexType>
								</xs:element>
							

TD Examples

In the following, we give three examples of a full TD. The first one, a temperature sensor, shows how to define relations between Thing Properties. As a second example, we modeled an actuator (LED lamp) where Actions have all been characterized semantically, so that machines could unambiguously interpret them in an automated manner. At last, association between Things is shown by defining a master switch controlling other LED lamps.

Temperature Sensor

							{
							  "@context": ["https://w3c.github.io/wot/w3c-wot-td-context.jsonld",
							               "https://w3c.github.io/wot/w3c-wot-common-context.jsonld"],
							  "@type": "Sensor",
							  "name": "myTempSensor",
							 "base" : "coap:///www.example.com:5683/temp/",
							  "interactions": [
							    {
							      "@id": "val",
							      "@type": ["Property","Temperature"],
							      "unit": "celsius",
							      "reference": "threshold",
							      "name": "myTemp",
							      "outputData": {"valueType": { "type": "number" }},
							      "writable": false,
							      "links": [{
							      	"href" : "val",
							      	"mediaType": "application/json"
							      }]
							    }, {
							      "@id": "threshold",
							      "@type": ["Property","Temperature"],
							      "unit": "celsius",
							      "name": "myThreshold",
							      "outputData": {"valueType": { "type": "number" }},
							      "writable": true,
							     	"links": [{
							      	"href" : "thr",
							      	"mediaType": "application/json"
							      }]
							    },
							    {
							      "@type": ["Event"],
							      "outputData": {"valueType": { "type": "number" }},
							      "name": "myChange",
							      "property": "temp",
							       "links": [{
							      	"href" : "val/changed",
							      	"mediaType": "application/json"
							      }]
							    }, {
							      "@type": ["Event"],
							      "outputData": {"valueType": { "type": "number" }},
							      "name": "myWarning",
							      "hrefs": ["val/high"]
							    }
							  ]
							}
						

The Thing myTempSensor defines two Properties: myTemp and myThreshold. Both are defined as temperatures, with the same unit (celsius). A client that is able to parse a TD only needs to know the predicate reference to understand that the threshold acts as a reference value for myTemp while the latter is the actual value measured by the temperature sensor. Here, reference points to http://schema.org/valueReference.

Moreover, one of the Events of the Thing is linked to the measured value (with the predicate property). It means in that context that an event should be triggered each time myTemp changes. The other Event does not define further semantics, it could be used either in a closed system (where clients are aware of its meaning) or by a human but an external agent would not have sufficient information to interpret it.

LED Master Switch

							{
							  "@context": ["https://w3c.github.io/wot/w3c-wot-td-context.jsonld",
							               "https://w3c.github.io/wot/w3c-wot-common-context.jsonld"],
							  "@type": "Lamp",
							  "name": "myMasterLED",
							  "interactions": [
							    {
							      "@type": ["Actions", "Toggle"],
							      "name": "myMasterOnOff",
							      "inputData": {
							        "@type": "OnOff",
							        "valueType": { "type": "boolean" }
							      },
							      "links": [
							      {
							        "href" : "coap://www.example.com:5683/master",
							        "mediaType": "application/json"
							      },{
							        "href" : "http://www.example.com:80/master",
							        "mediaType": "application/json"
							      }]
							    }
							  ],
							  "associations": [
							    { "hrefs": ["coap://www.example.com:5683/0"] },
							    { "hrefs": ["coap://www.example.com:5683/1"] },
							    { "hrefs": ["coap://www.example.com:5683/2"] },
							    { "hrefs": ["coap://www.example.com:5683/3"] },
							    { "hrefs": ["coap://www.example.com:5683/4"] },
							    { "hrefs": ["coap://www.example.com:5683/5"] },
							    { "hrefs": ["coap://www.example.com:5683/6"] },
							    { "hrefs": ["coap://www.example.com:5683/7"] }
							  ]
							}
						

In this last example, we illustrate the use of associations. The Thing we modeled here acts as a master switch for eight lamps similar to that of . It means switching on and off myMasterOnOff will propagate to all associated Things by toggling their Action that is also of type Toggle.

No precise semantics for associations have been defined yet and there might exist many other kinds of dependency between Things than simply parent/child relation. This issue will be addressed soon. Until then, Thing associations could be useful for discovery.

Usage

Extending Thing Description with Other Semantic Models

As the TD context we have developed is intended to be minimal, it is strongly recommended to extend it for each Thing by reusing other vocabularies or ontologies and/or defining application-specific terms. In the following example, in addition to our standard context, the context of the Thing declares a namespace pointing to a shared vocabulary for domotics called DogOnt:

								{
								  "@context": ["http://w3c.github.io/wot/w3c-wot-td-context.jsonld",
								               {"dogont": "http://elite.polito.it/ontologies/dogont.owl#"}],
								  ...
								}
							
DogOnt defines hundreds of concepts ranging from HVAC to units of measurement.

During early experimentations with TD files, a few concepts and terms appeared to be recurrent, such as Temperature, Toggle or unit. To ease experimentation with the modeling of Things, a context that gathers such common terms has been defined at http://w3c.github.io/wot/w3c-wot-common-context.jsonld. Its content simply defines aliases for classes and properties of well-known ontologies that are relevant for our activity: DogOnt, Quantity Kinds & Units, LinkedGeoData and Schema.org. This file will likely be frequently updated and is not intended to become a reference. It should always be used along with the standard TD context, as follows:

								{
								  "@context": ["http://w3c.github.io/wot/w3c-wot-td-context.jsonld",
								               "http://w3c.github.io/wot/w3c-wot-common-context.jsonld"],
								  ...
								}
							

@TODO more details on contextual semantics (e.g., domain independent and dependant semantic models, ontologies etc.).

Discovery

This section describes in general how a Thing (i.e., its TD) can be discovered. In particular, the current practices at the PlugFests should become clear. Technology-specific mechanisms such as BLE Beacons or UPnP multicast requests should go into the corresponding sub-sections of .

Discovering a Thing means acquiring a link to its TD, which then contains all the information to interact with it and understand its data. The URI of the link may point to the Thing (technically the servient) itself, as Things often host their TD directly, or to any other location on the Web. There are several approaches to aquire such links. Some work independent from the Protocol Binding, others rely on features of a specific protocol.

Manual Discovery

The link to the TD is provided by the developer at programming time, the operator through device management, or the user through a UI.

Repository

The Thing (or a commissioning tool) registers the TD with a well-known repository, which also provides a look-up mechanism (potentially supporting filtering).

The figure shows the basic concept of the usage of a repository: 1) A servient register its TD to a known TD repository. 2) Another servient does a lookup/search/querying (e.g., via SPARQL) at the TD repository. 3) The repository answers with one ore more relevant TDs. Also a subset of TD’s content can be in the result set (e.g., only relevant properties, actions, and/or events are included). 4) Based on the repository’s result set, a connection can be initiated.

Local Discovery

The Thing is able to broadcast a discovery request locally (e.g., a CoAP multicast request for /.well-known/core) or to receive announcements from its proximity (e.g., BLE Beacons). The response to a discovery request can include the TD directly or just a link. For announcements, it is more common to only provide a link, since broadcasting TDs can be expensive.

Security

@TODO Add howto about security metadata and how to use it

Scripting API

The Scripting API is an API specification to have a uniform way to write scripts/applications for the web of things. It provides means for Discovery, Provisioning and Control of Things in a Web of Things.

Portable application logic, language-independent

API design principles

The API is designed to be language-agnostic (i.e. being applicable to different languages) to enable various runtimes. The overall API philosophy is reactive, meaning a programmer will mostly be passing callback functions which get called from the framework. It makes uses of the promise pattern that is very popular in Javascript.

The API aims to provide means for both exposing things (as a server) and consuming things (as a client). They can be retrieved from a singular entry point, it offers factory methods to create representations of exposed and consumed things. These representations offer methods to define behaviour for a thing, change the thing model or interact with the thing.

Object orientation: This document is written language agnostic, but is specified using object oriented metaphors. This document will capture a proposition for the structure of the WoT scripting API and state the design principles.The translation of this metaphors for non-object oriented languages (most notably C) can be done by passing handles and structs, which is common practise, but needs further specification. Some ground rules can be named however: all functions shall have a prefix handles or structs replace passing of objects to the framework structs represent objects being passed from the framework.

WoT root entry

The root entry for the API is an object WoT giving access to the factory methods.
For non-object oriented languages, you could use wot- as a prefix to the factory methods.

						interface WoT {
							Promise<sequence<ConsumedThing>> discover(ThingFilter filter);
							Promise<ConsumedThing> consumeDescription(object td);
							Promise<ConsumedThing> consumeDescriptionUri(DOMString uri);
							Promise<ExposedThing> createThing(DOMString name);
							Promise<ExposedThing> createFromDescription(object td);
							Promise<ExposedThing> createFromDescriptionUri(DOMString uri);
						};
					

Factories for Consuming Things

Instances of the objects/structs representing a Thing are retrieved via factories. These are methods of the root object that return a promise which will resolve to an array of proxy objects.

factory discover()

Discovery of Things can be triggered with typed filters.

Parameters
  • type type of the discovery mechanism
  • filter object (dictionary) with parameters for the discovery
Returns

A promise resolved to an array of ConsumedThing and rejected if the discovery type is not available or there was an error

								WoT.discover("registry", {registry:"http://my.registry.org"})
								.then(function(things) {
									things.forEach(function(thing) { 
										console.log("found " + thing.name);
									});
								})
							

factory consumeDescription()

This factory method can be used to create Things based on a Thing Decription

Parameters
  • td a Thing Description
Returns

A promise resolved to a ConsumedThing and rejected if the thing is not available or there was an error

								WoT.consumeDescription({ /*... valid thing description ...*/ })
								.then(function(thing) {
									console.log("found " + thing.name);
								});
							

factory consumeDescriptionUri()

This factory method can be used to create Things based on a uri of a Thing Decription

Parameters
  • uri an uri pointing to a Thing Description
Returns

A promise resolved to a ConsumedThing and rejected if the thing is not available or there was an error

								WoT.consumeDescriptionUri("http://somethingontheweb.org/td")
									.then(function(thing) {
										console.log("found " + thing.name });
									})
							

Factories for Exposing Things

Instances of the objects/structs representing a Thing are retrieved via factories. These are methods of the root object that return a promise which will resolve to a proxy object.

factory createThing()

This factory method can be used to create new Things

Parameters
  • name the name of the newly created Thing
Returns

A promise resolved to an ExposedThing and rejected if the thing could not be created or there was any error

								WoT.createThing("Foo")
									.then(function(thing) {
										console.log("crated " + thing.name });
									})
							

factory createFromDescription()

This factory method can be used to create new Things based on a TD template

Parameters
  • td a Thing Description template describing the interactions of the Thing
Returns

A promise resolved to an ExposedThing and rejected if the thing could not be created or there was any error

								WoT.createFromDescription({"name" : "Foo", "actions" : [/* ... */] })
									.then(function(thing) {
										console.log("crated " + thing.name });
									})
							

factory createFromDescriptionUri()

This factory method can be used to create new Things based on a TD template, given by a uri pointing to the TD template.

Parameters
  • uri a uri poinzing to the Thing Description template describing the interactions of the Thing
Returns

A promise resolved to an ExposedThing and rejected if the thing could not be created or there was any error

								WoT.createFromDescriptionUri("http://some.server.org/tdtemplate.jsonld")
									.then(function(thing) {
										console.log("crated " + thing.name });
									})
							

Consumed Thing

The root entry for a placeholder object to interact with a Thing

						interface ConsumedThing {
								readonly attribute DOMString name;
							    Promise<any> invokeAction(DOMString actionName, any parameter);
							    Promise<any> setProperty(DOMString propertyName, any newValue);
							    Promise<any> getProperty(DOMString propertyName);
								ConsumedThing addListener(DOMString eventName, ThingEventListener listener);
							    ConsumedThing removeListener(DOMString eventName, ThingEventListener listener);
							    ConsumedThing removeAllListeners(DOMString eventName);
								object getDescription();
						};
					

explanation in detail to be transferred from Proposal

Exposed Thing

The root entry for a placeholder object to define behaviour for a Thing

						interface ExposedThing {
								readonly attribute DOMString name;
							    Promise<any> invokeAction(DOMString actionName, any parameter);
							    Promise<any> setProperty(DOMString propertyName, any newValue);
							    Promise<any> getProperty(DOMString propertyName);
								Promise<any> emitEvent(DOMString eventName, any payload);
								ExposedThing addEvent(DOMString eventName, object payloadType);
								ExposedThing addAction(DOMString actionName, object inputType, object outputType);
								ExposedThing addProperty(DOMString propertyName, object contentType);
								ExposedThing onInvokeAction(DOMString actionName, ActionHandler callback);
								ExposedThing onUpdateProperty(DOMString propertyName, PropertyChangeListener callback);
								ExposedThing addListener(DOMString eventName, ThingEventListener listener);
							    ExposedThing removeListener(DOMString eventName, ThingEventListener listener);
							    ExposedThing removeAllListeners(DOMString eventName);
								object getDescription();
						};
					

explanation in detail to be transferred from Proposal

Security Considerations

This section outlines the conception behind the WoT security model. The following security concerns apply:

These two security concerns are orthogonal: signing TD objects may be needed for TD objects which do not express any security-related expectation for accessing Things. On the other hand TD objects may express such expectations without being signed.

Security Enforcement at the WoT Interface

The purpose of WoT is to expose private resources (Things themselves, information they produce, or information about them) at public-facing endpoints (e.g., Internet). This implies that components that expose Things (i.e., servients) must enforce security: credentials have to be presented, communication exchanges have to be encrypted/signed etc. There are two basic clusters of security features which are relevant for servients:

  • Authorization and authentication
  • When receiving instructions, servients must authorize such calls/requests i.e. determine whether to accept them for processing. This implies the need to authenticate the properties of callers that are used when performing authorization.
  • Secure communications
  • When exchanging sensitive resources/information over a shared network, servients must demand encrypting/signing corresponding message exchanges.
These fundamental security services depend on underpinnings esp. the provisioning of metadata (identifiers, attributes, assignments/affiliations) about system actors and the establishment of keying relations resp. shared secrets among actors that are supposed to interact in protected fashion. This section does not further elaborate on the provisioning of metadata and establishment of keys/secrets needed to implement authoriztion and authentication resp. secure communications.

Authorization and Authentication

The authorization of requested actions (instructions/requests) depends on the authentication of those properties of a caller that are relevant for authorization and that are being submitted or claimed by the caller. This can e.g. be identifiers, attributes (e.g. location), assignments (e.g. roles), affiliations (e.g. group memberships) or permissions (e.g. resource access rights). There are two basic strategies for the initial authentication of callers:
  • Internalization
  • The servient challenges the caller for initial authentication credentials, validates them, determines the properties of the authenticated caller, uses them to render an authorization decision and enforces this decision.
  • Externalization to online TTPs
  • The servient delegates the challenging for initial authentication credentials, their validation, the determination of caller properties and evtl. the rendering of an authorization decision to an online TTP. In course of that the servient then receives a report of the TTP (corresponding objects are called 'security token' or 'access token') and proceeds with it
The internalization approach has a number of issues including: lack of SSO (a concern when the caller is a user agent, no real issue otherwise), tight coupling of initial authentication credentials and application protocol (a painpoint when multiple schemes/dynamics are to be covered), forcing servients into the implementation of complex, non-core functionality. For these reasons the internalization strategy is uncommon - even in unconstrained office/enterprise/Cloud IT. Since WoT is concerned with components that are (severly) constrained, it is anticipated that WoT solutions will externalize complex processing tasks in caller authentication to online TTP components by default.
The externalization of initial caller authentication to TTPs allows to allocate the authorization decision making as follows:
  • Internalization
  • The servient component performs authorization decision making and enforcement
  • Externalization according push
  • The servient component performs authorization decision enforcement. Authorization decision making is done by the TTP that performs the initial authentication of callers (resource access control information travels in-band with the security token asserting the authenticated identity of the caller)
  • Externalization according pull
  • The servient component performs authorization decision enforcement. Authorization decision making is done by a backend component (called by the servient).
The externalization of initial caller authentication and the externalization of the authorization decision making according push to TTPs matches the architectural proposition of the IETF ACE working group (see "An architecture for authorization in constrained environments" at https://www.ietf.org/id/draft-ietf-ace-actors).

The anticipated default strategy in WoT results in online TTP components as well as special-purpose objects: security tokens by which online TTPs report the results of their work back to servients. These are cryptographically protected objects that report properties of the caller (identifiers, attributes, assignments, affiliations, permissions etc) which are asserted by the online TTP. Such objects may contain resource access control information. Such objects are short-lived (normally: minutes/hours) and may be re-used during their lifetime. These objects must be signed to prevent counterfeiting and may be encrypted to preserve confidentiality.
  • Bearer security model
  • In case of bearer tokens submitters of security tokens do not have to provide any proof-of-possession. A real-life analogy is a cinema or concert ticket - the recipient only wants to make sure it is no counterfeit. This implies a risk that illegitimate callers may present valid security tokens. In the digital World SAML Web SSO is a prominent example of an online TTP scheme that is implementing a bearer model.
  • PoP security model
  • In case of PoP (aka HoK) tokens submitters are required to supply fresh authenticator objects in addition/conjunction with security tokens. A real-life analogy is a passport - the recipient wants to make sure it is no counterfeit and is presented by the right person. In the digital World Kerberos is the most prominent example of an online TTP scheme that is implementing a PoP model.
Note that OAuth started with PoP (OAuth 1.x), moved to bearer (OAuth 2.0 according RFC 6749/6750) to foster adaptation and currently adds PoP (current OAuth 2.0 drafts) to include high-value assets.

In WoT no one-size-fits-all security token should be expected. Specific WoT domains such as building automation, sports/health care, industrial control systems have their own specific needs when it comes to the expression of caller properties. Moreover specific protocol stacks also have their own specific constraints that affect security token contents.

In addition to security tokens (that are domain and protocol stack-specific) protocols are needed to acquire and supply security tokens. The security token supply between callers and servients is the straight-forward part of this task:
  • Application requests
  • The application protocol requests must allow the transfer of security tokens (bearer) and/or authenticators (PoP) in a standardized way. For HTTP such standards exist (RFC 6750 for bearer tokens) resp. emerge (PoP tokens); for CoAP they do emerge. A critical issue are large security tokens/authenticators that can not be supplied inline with arbitrary application requests. The common trick to address this concern is to introduce a dedicated endpoint to which security tokens and/or authenticators can be sent in application PDUs (dedicated to the supply of security tokens and/or authenticators) during in an upfront exchange.
  • Application responses
  • The application protocol (error) responses must allow to inform clients about expected security token issuing authority, expected security token type/category and protection. Current and emerging standards do not yet provide an adequate coverage for this concern.
The security token acquisition is the more complex part of this trick. The servient components trigger exchanges between callers and their online TTP but are not involved during their execution. The requesting party may also introduce further online TTP components to support e.g. constrained callers or clients. Obviously the online TTPs need to respect the capabilities of the actual caller or its proxy. In addition to that a continental divide exists between following scenarios:
  • Consumer goods, owned by individual end users
  • Authorization is often conducted according a lazy policing model: access requests happen first, then the resource owner (an individual) is asked for an authorization (whether she can be assumed to be online does matter). This results in an authorization policy that is build-up dynamically
  • Capital goods, owned by legal entities
  • Authorization is mostly conducted according a preemtive policing model: a (static) authorization policy is provided, then access request happen and authorization decisions are rendered without assuming any interaction with the resource ownwer or a representative
Both cases distribute work unevenly over servients and their callers; both sides have fundamentally different working tasks and workloads in authorization and authentication:
  • Servient tasks
  • Understand protection needs (public, private) of served resources, challenge for security tokens (bearer) and/or authenicators (PoP), validate security tokens (bearer) and/or authenicators (PoP) and match their content against application request contents
  • Caller tasks
  • React on application protocol error responses (demanding the supply of security tokens), acquire security token from online TTPs, perform initial authentication by means of a security protocol (possibly different from the application protocol, evtl. mediated by an online TTP on side of the requesting party), and supply security tokens (bearer) and/or authenticators (PoP) as part of the application protocol
For client-side and server-side support APIs this obvious results in fundamentally different security task that have to be facilitated by WoT Interfaces. The security-part of the W3C WoT PlugFest in Nice showed the ability to create mutually interoperable and security-enabled WoT component implementations (by different vendors). The security-enabling at the PlugFest focussed on the authorization of actions (sent to servients) and the authenticator of actors (WoT clients). It utilized online third-party components to which the servients and clients delegated the complex processing tasks in authorization and authentication and utilized trusted assertions (aka access/security tokens) to report back to servients and clients. This follows architetural models and protocols which emerge from IETF working groups (including OAuth and ACE). See https://www.w3.org/WoT/IG/wiki/F2F_meeting_2016,_January,_26th_%E2%80%93_28th,_France,_Nice#Security for more info about the security-enabling and its results for this PlugFest

Secure Communications

Communication security can be implemented in form of transient, transport-level security (e.g. TLS, DTLS) and/or persistent, application-level security (e.g. JOSE, COSE). Both approaches result in symmetry with respect to the work-split across servients and their callers; both sides basically have the same working tasks and workload

Transport-level security has a long heritage in IT and presents a well-understood means in Web security which is carrying critical use cases. If TLS resp. DTLS match the constraints of WoT deployments they should be used to secure communications.

Some WoT deployments have requirements that do not match TLS and DTLS properties, for instance multicast resp. group-oriented communications. It is also possible that (severely) constrained WoT components can not bear the overhead that is implied by the TLS and DTLS protocols. Then persistent, application-level security can help to achieve communication security.
In contrast to transport-level security, application-level security allows to apply cryptographic transformations in a specific/granular manner (affecting some but not all exchanged data objects) and thereby reducing the security processing burden. In case security tokens are to be used in cases where transport-level security can not be used, application-level security offers means to provide PoP for security tokens as well as authenticity for message exchanges.

Describing Prerequistes for Accessing Things

When private resources (Things themselves, information they produce or information about them) get exposed at public-facing endpoints (e.g. Internet) then the components that are exposing theThings (i.e., servients) must enforce security: credentials have to be presented, communication exchanges have to be encrypted/signed etc. There are two basic strategies for demanding such security mechanisms:

  • A priori
  • Callers know beforehand and make requests according the expectations of the callee. A prominent example for this strategy is the 'https' access scheme in URLs. It triggers clients to employ SSL/TLS in order to send HTTP requests (HTTP-over-TLS, RFC 2818).
  • A posteriori
  • Callers do not know beforehand, make a request and are being told by the callee in the response or during the exchanges. An example for this strategy is the negotiation of the use of SSL/TLS as part of HTTP exchanges (TLS-in-HTTP, RFC 2817).
The a posteriori-strategy places requirements on the application protocol esp. the contents of its error responses, not TD. In case of WoT, the a priori-strategy places requirements on TD: TD needs to be able to express security mechanisms that callers have to fulfill. This expression shall be optional because certain WoT deployments might prefer the a posteriori-strategy and do (intentionally) not want to reveal this information in TD objects.
Authorization and Authentication
This section assumes that servients externalize complex processing tasks around call authorization and caller authentication to security components (representing online TTPs). See below for a rationale.
Following items are needed to inform callees about security credentials/tokens that they have to present for specific resources:
  • Issuing authority of the security token
  • Callers need to know about the online TTP component where they need to apply for security tokens. This includes information about their configuration encompassing endpoints and supported protocols.
  • Type/category of security token
  • Callers need to know which type(s) or categories of security tokens they need to apply for. An individual security token type or category is assumed to expressed by a URN (in the namespace of the security token issuer).
  • Protection model for security token
  • Callers need to know the protection model of the security tokens they need to apply for. Note that bearer token are submitted in a opaque fashion, for PoP tokens an authenticator has to be created by the caller.
Secure Communications
Transient Protection, Transport-Level Security

The URL access scheme allows to express the need for secure communications (SSL/TLS or DTLS). This is part of the resource endpoint URL and there is no need for TD to specify any additional means. Note that 'http' vs. 'https' resp. 'coap' vs. 'coaps' carries only boolean information. The suite of parameters that determine SSL/TLS or DTLS sessions is much larger (encompassing authentication modes and related information, encryption/signature strategies). Hence the URL access scheme does not provide a full or even rich announcement of the required settings. Since it is the best current practice in IT to rely on a simple a priori trigger (in URL access scheme) and do the rest of the work accordng the a posteriori-apporach (inband with the security protocol) there is no need for TD resp. WoT to go beyond.

Persited Protection, Application-Level Security
Application-level security providing persisted protection is usually handled by specifications/conventions in the application domain. This uses specific media types such as application/json for JSON-plain and application/jose for protected JSON objects (JWS/JWE). Note that application/cbor does exist but there is not yet a IANA registration for "application/cose" (as of 2016-02-21, see http://www.iana.org/assignments/media-types).

TODO (@TF TD): the datatype part in XML Schema (https://www.w3.org/TR/xmlschema11-2/) seems to be short with respect to being able to speak about cryptographically transformed data (see RFC 7193 for e.g. application/cms). It seems hard to impossible to allow callees to express security requirements wrt to persitent application-level security based on that. I suggest to either disclaim this case or allow richer data types

Protecting TD Objects

TD objects may be protected by means of signature. Signing TD objects is optional.

If TD objects are signed then cryptographic checksums (aka signatures) are added to establish the authenticity of TD objects. Such checksums are created by the producers/issuers of TD objects and validated by consumers of TD objects (which should reject signed TD objects whose signatures are invalid). They use keying associations between the producer of the protected TD objects and its consumer(s). The checksum resp. keying association can be asymmetric (producer signs with a private key, consumers validate with the corresponding public key) or symmetric (producer and consumer use a shared secret key).
For TD objects expressed in JSON, IETF JOSE (JSON Object Signature and Encryption, see https://datatracker.ietf.org/wg/jose/documents/) provides the standards for computation and validation of signatures and their representation as network transfer objects (RFC 7515).

Signing is straight-forward on the level of cryptographic primitives i.e. algorithms to generate and validate checksums. But the cryptographic algorithm that computes the checksum only reduces the amount of data that has to be protected - from potentially large (TD) to small (key) objects. Sound key management practices are needed behind the scene. Key management largely contributes to the overall price-tag of the security solution. It is also not straight-forward on the level of cryptographic objects i.e. the expression and organization of signed data and signature metadata (information about the embedding/location and transformation/normalization of signed data, information about the signature algorithm as well as the keying association etc). The solution design needs to reflect given or anticipated WoT system dynamics with respect to granularity/pooling of TD object signing. This presents a not yet addressed problem.

On top of a commonly signature object specification such as XML Signature or CMS lots of profiling may be needed in order to make a signature mechanism meaningful for a specific domain. This is illustrated by the IETF ltans effort: IETF ltans addressed the long-term archival of digital data objects and produced a number of RFCs (RFC 4810/4998/5276/5698/6238) on top of XML Signature resp. CMS that were needed to do the trick. Another example is XAdES (https://www.w3.org/TR/XAdES/). Note: this does not try to suggest that the signing of TD objects will have the same added complexity as IETF ltans or W3C XAdES, only that specific conventions/profiles for the use of JWS or XML Signature in the TD domain will be needed.

PlugFests

This section includes the goals and ideas of each WoT PlugFest in chronological order. Before reflecting the "lessons learned" of each PlugFest, which drove the development of the presented practices, the document provides a howto for participating in the PlugFests.

@TODO Add more detailed information along with pictures of each plugfest

Participation Howto

The current status of the howto is Beijing (2016-07)

This howto is kept up to date with the requirements for the latest/upcoming edition of the PlugFest. To participate in an upcoming PlugFest, prepare an implemention by deciding on the following questions. The answers to these questions will also be needed when registering for a PlugFest by filling out a table in the corresponding PlugFest page in the WoT IG Wiki. Note that there might be additional options in the future when more features are defined or more Protocol Bindings become popular in the PlugFest.

What to Implement?

  1. WoT Client (e.g., a Web dashboard)
    A WoT client implementation requires a TD parser and a user interface or control logic to drive the interaction with one or more other Things. Optionally, it can implement lookup support for the Repository (also see 3.2.6.2.2 Repository. An HowTo how such a lookup can be realised can be found here. For the TD parser, a JSON-LD library is recommended, but it is also possible to implement a simpler parser that exploits knowledge about which parts of the TD are actually relevant for the Thing. Simple WoT clients can have a limited notion of the semantics and only support interactions that match their own capabilities. A simple switch, for instance, does not need to understand the RGB color model. Powerful WoT clients, however, may have full RDF support and require access to Linked Data to reason about the metadata and interactions provided by the TD.
  2. WoT Server (e.g., a Thing that only provides functionality, but does not use other Things)
    A WoT server requires resource handlers that implement Properties, Actions, or Events. The TD can vary between static or dynamically generated based on the implementd interactions. For this, a simple JSON library is enough, as the vocabulary is fully known at design time. A WoT server should also implement support for TD Repository registration. A registration HowTo can be found here.
  3. WoT Servient (e.g., a virtual Thing that composes multiple other Things and provides a higher-level TD)
    A WoT servient is capable of thing-to-thing interaction. It needs to implement both server and client requirements. The server part is usually used to configure the Thing, so it knows which interaction to select on the other Thing(s). A powerful Thing might only need rough information such as all Things at location X and then uses semantic match between itself and the capabilities of the discovered Things. A smart switch, for instance, has the notion of being on or off, and hence binds to the first onOffStatus interaction it finds on discovered lamps. Resource-constrained Things usually need the exact wiring configuration by a user or comissioning tool. A smartphone app, for instance, can be used to write the TD of a specific lamp together with the @id value of the desired interaction to the configuration Properties of a energy-harvesting switch. The client part then starts the interaction with the other Thing(s) by constructing messages based on the given TD and implemented Protocol Bindings.

Which Protocols to Support?

  1. HTTP
    The classic Web protocol is currently most common for clients (e.g., with a Web UI) and more powerful Things. There is a plethory of HTTP frameworks available for most languages and platforms.
  2. CoAP
    This protocol is predominant for resource-constrained Things. Several different CoAP implementations and frameworks can be found here.
  3. Additional Protocols
    To evaluate more Protocol Bindings, implementors are welcome to bring Things with alternative protocol stacks to the PlugFests. Some protocols might require a shim layer to allow for the resource model of WoT.

What Security Modes to Support?

  1. NoSec (there is no security involved)
  2. Request authorization (i.e., using JSON Web Tokens (JWT))
    1. Simple (i.e., bearer security token only)
    2. Advanced (i.e., token with access control information in style of AIF [draft-bormann-core-ace-aif-03])
  3. Message authentication and encryption (i.e., using (D)TLS)

How to Implement the Application Logic?

  1. Native Code
  2. The application logic is implemented directly in the firmware or a supported language of the protocol framework. This is the default for resource-constrained Things that serve a specific purpose.
  3. Scripting
    Having the application logic in scripted apps means that the servient must implement a runtime environment that provides the Scripting API. Node.js may provide a good initial prototype for a WoT runtime environment on more powerful Things or cloud servients. In the embedded world, Lua is a popular scripting language that could be used for portable apps.

Sapporo (2015-10)

This first WoT PlugFest elaborated, based on a JSON-LD Thing Description, server and client role of a Thing. Protocols such as CoAP, HTTP and WebSocket were combined with JSON and EXI data formats.

More information can be found on the dedicated wiki page.

Goals

  • Interoperable applications by means of a Thing Description only

Outcome & Findings

  • Thing description registry and discovery is needed

Nice (2016-01)

Goals

Based on the previous PlugFest in Sapporo four advances will be proposed (more information can be found on the dedicated wiki page).

  • Security: using new security mechanisms that emerged for protecting new styles of Web applications (Web/REST APIs, browser-based/mobile apps) in the Things space
  • APIs: generic APIs to program behavior for a Thing or interact with a Thing
  • Thing registries: practical registration and discovery of a Thing
  • HATEOAS: application of REST-based hypermedia controls in the Thing world

Outcome & Findings

  • Thing Description
    • Protocols: how to set up IP addresses?
    • How to setup data types with restrictions, e.g. with ranges?
    • Security: Which resources has access restrictions?
    • How to deal with the situation a Thing changes its capabilities?
    • How to share interactions of a TD across several Things?
    • De-coupling: semantics / relation types from links
    • REST-based topics:
      • Resource hierarchy missing (no parentOf and/or childOf)
      • Relative links vs. absolute links in interaction models
    • How to include more semantics / other context
  • Scripting API
    • "Server"-side API is missing and needs to be added
  • Security Findings (details can be found here)
    • The security token form-factor CWT was unavailable due to lack of signature/encryption support in current CBOR libraries
    • The security token form-factor JWT is versatile but lacks a standard way of distinguishing different types
    • CoAP lacks adaptation of the HTTP authorization framework (RFCs 2617/7235)
    • CoAP stacks lack programmatic/declarative ways of telling the runtime to enforce the presence of valid security tokens (for certain resources)
    • WoT lacks consideration on whether that should be expressed in Thing Descriptions (opt. item for domains that prefer a-priori strategies)
    • OAuth resp. ACE miss some coverage for cross-domain cases

Montreal (2016-04)

Find PlugFest organization and contributor details on the dedicated WoT Montreal PlugFest wiki page.

With this PlugFest we would like to move on from testing the practices in this document to actually accomplishing real-world scenarios.

Goals

Compared to previous PlugFests we do not plan to introduce new technologies nor additional parts. Instead we focus on a broader support of the same features by different implementations.

Moreover, we especially encourage real-world scenarios in the following two areas:

Former PlugFest participants are well aware of the available actuation and sensing capabilities of Things. That said, we would like to stimulate new scenarios based on what we have seen so far (e.g., discover Properties and combine them with Actions and/or Events of other Things). Feel free to come up with rather sophisticated real-world use-cases. Please also make use of the discovery to improve PlugFest preperation and enable onsite combination of Things.

It is time to stress what we elaborated so far to actually proof it!

Outcome & Findings

  • TBD

Conclusions

What decisions came out of discussions at phone or F2F meetings. Keep arguments here why solutions were discarded or why the practice is as it is.

Outlook

...

Acknowledgements

We would like to thank all PlugFest participants who helped to improve the practices given in this document.

Change History

List changes over publications and their rational...