index.html

<!DOCTYPE html>
<html lang='en-US'>
<head>
  <!-- link rel="stylesheet" href="testing/atrisk.css" -->
  <meta charset='utf-8'>
  <title>Web of Things (WoT) Architecture 1.1</title>
  <script class="remove" src="https://www.w3.org/Tools/respec/respec-w3c"></script>
  <script class="remove">
    var respecConfig = {
      lint: {
        "check-punctuation": true,
        "local-refs-exist": true,
        "no-http-props": true,
        "no-headingless-sections": true
      },
      doJsonLd: true,
      noLegacyStyle:  true,
      inlineCSS:      true,
      noIDLIn:        true,
      group: "wg/wot",
      specStatus: "ED",
      shortName: "wot-architecture11",
      copyrightStart: 2017,
      wgPublicList: "public-wot-wg",
      implementationReportURI: "https://w3c.github.io/wot-architecture/testing/report11.html",
      github: {
        repoURL: "https://github.com/w3c/wot-architecture",
        branch: "main"
      },
      previousPublishDate: "2022-09-07",
      previousMaturity: "WD",
      editors: [
        {
          name: "Michael Lagally",
          w3cid: "47166",
          company: "Oracle Corp.",
          companyURL: "https://www.oracle.com/"
        }, {
          name: "Ryuichi Matsukura",
          w3cid: "64284",
          company: "Fujitsu Ltd.",
          companyURL: "https://www.fujitsu.com/"
        }, {
            name : "Michael McCool",
            w3cid : "93137",
            company : "Intel Corp.",
            companyURL : "https://www.intel.com/"
        }, {
          name: "Kunihiko Toumura",
          w3cid: "83488",
          company: "Hitachi, Ltd.",
          companyURL: "https://www.hitachi.com/"
        }],
      formerEditors: [
        {
          name: "Kazuo Kajimoto",
          note: "when at Panasonic Corp."
        }, {
          name: "Toru Kawaguchi",
          w3cid: "79307",
          company: "Panasonic Corp.",
          companyURL: "https://www.panasonic.com/"
        }, {
           name: "Matthias Kovatsch",
           company:    "Huawei",
           companyURL: "https://www.huawei.com"
        }],
      otherLinks: [{
          key: "Previous Recommendation",
          data: [{
            value: "https://www.w3.org/TR/2020/REC-wot-architecture-20200409/",
            href: "https://www.w3.org/TR/2020/REC-wot-architecture-20200409/"
          }]
        }, {
          key: "Contributors",
          data: [{
            value: "In the GitHub repository",
            href: "https://github.com/w3c/wot-architecture/graphs/contributors"
          }]
        }, {
          key: "Repository",
          data: [{
            value: "We are on GitHub",
            href: "https://github.com/w3c/wot-architecture/"
          }, {
            value: "File a bug",
            href: "https://github.com/w3c/wot-architecture/issues"
          }]
        }],
      localBiblio: {
        "CoRE-RD": {
          href: "https://datatracker.ietf.org/doc/html/draft-ietf-core-resource-directory-21",
          title: "CoRE Resource Directory",
          authors: ["M. Koster", "C. Bormann", "P. van der Stok", "C. Amsuess"],
          status: "Internet-Draft",
          publisher: "IETF",
          date: "13 June 2019"
        },
        "IEC-FOTF": {
          href: "https://www.iec.ch/basecamp/factory-future",
          title: "Factory of the future",
          publisher: "IEC",
          date: "October 2015"
        },
        "IOT-SCHEMA-ORG": {
          href: "https://www.w3.org/community/iotschema/",
          title: "Schema Extensions for IoT Community Group"
        },
        "REST": {
          href: "https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf",
          title: "REST: Architectural Styles and the Design of Network-based Software Architectures",
          authors: ["Roy Thomas Fielding"],
          status: "PhD thesis",
          publisher: "University of California, Irvine",
          date: "2000"
        },
        "SAREF": {
          href: "https://sites.google.com/site/smartappliancesproject/ontologies/reference-ontology",
          title: "Smart Appliances REFerence (SAREF) ontology",
          publisher: "ETSI",
          date: "November 2015"
        },
        "SOLID": {
          href: "https://solidproject.org/TR/",
          title: "Solid Technical Reports",
          publisher: "W3C Solid CG",
          date: "April 2021"
        },
        "HCI": {
          href: "https://www.interaction-design.org/literature/book/the-encyclopedia-of-human-computer-interaction-2nd-ed",
          title: "The Encyclopedia of Human-Computer Interaction, 2nd Ed",
          publisher: "Interaction Design Foundation",
          date: "2013"
        },
        "NORMAN": {
          title: "The Psychology of Everyday Things",
          authors: ["Donald A. Norman"],
          publisher: "Basic Books",
          date: "1988"
        },
        "MQTT": {
          href: "https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html",
          title: "MQTT Version 3.1.1 Plus Errata 01",
          authors: ["Andrew Banks", "Rahul Gupta"],
          publisher: "OASIS Standard",
          date: "December 2015"
        },
        "OCF": {
          href: "https://openconnectivity.org/developer/specifications/",
          title: "OCF Core Specification",
          publisher: "Open Connectivity Foundation",
          status: "Version 2.0.2",
          date: "April 2019"
        },
        "WOT-USE-CASES-REQUIREMENTS": {
          href: "https://www.w3.org/TR/wot-usecases/",
          title: "Web of Things (WoT) Use Cases and Requirements",
          publisher: "W3C",
          authors: ["Michael Lagally", "Michael McCool", "Ryuichi Matsukura", "Tomoaki Mizushima"],
          status: "Editor's Draft",
          date: "Oct 2020"
        },
        "LWM2M": {
          href: "https://openmobilealliance.org/release/LightweightM2M/V1_1-20180710-A/OMA-TS-LightweightM2M_Core-V1_1-20180710-A.pdf",
          title: "Lightweight Machine to Machine Technical Specification: Core",
          publisher: "OMA SpecWorks",
          status: "Approved Version: 1.1",
          date: "August 2018"
        },
        "CoRAL": {
          href: "https://datatracker.ietf.org/doc/html/draft-ietf-core-coral/",
          title: "The Constrained RESTful Application Language (CoRAL)",
          authors: ["Christian Amsüss","Thomas Fossati"],
          publisher: "IETF",
          status: "Internet-Draft",
          date: "March 2022"
        },
        "WOT-PIONEERS-1": {
          href: "https://pdfs.semanticscholar.org/3ee3/a2e8ce93fbf9ba14ad54e12adaeb1f3ca392.pdf",
          title: "Mobile Service Interaction with the Web of Things",
          authors: ["E. Rukzio, M. Paolucci", "M. Wagner, H. Berndt", "J. Hamard", "A. Schmidt"],
          publisher: "Proceedings of 13th International Conference on Telecommunications (ICT 2006), Funchal, Madeira island, Portugal",
          date: "May 2006"
        },
        "WOT-PIONEERS-2": {
          href: "https://escholarship.org/uc/item/1786t1dm",
          title: "Putting Things to REST",
          authors: ["Erik Wilde"],
          publisher: "UCB iSchool Report 2007-015, UC Berkeley, Berkeley, CA, USA",
          date: "November 2007"
        },

        "WOT-PIONEERS-3": {
          href: "https://www.vs.inf.ethz.ch/publ/papers/ostermai-poster-2008.pdf",
          title: "Poster Abstract: Dyser – Towards a Real-Time Search Engine for the Web of Things",
          authors: ["Benedikt Ostermaier",
            "B. Maryam Elahi",
            "Kay Römer",
            "Michael Fahrmair",
            "Wolfgang Kellerer"],
          publisher: "Proceedings of ACM SenSys 2008, Raleigh, NC, USA",
          date: "November 2008"
        },
        "WOT-PIONEERS-4": {
          href: "https://ieeexplore.ieee.org/abstract/document/5678452",
          title: "A Resource Oriented Architecture for the Web of Things",
          authors: ["Dominique Guinard", "Vlad Trifa", "Erik Wilde"],
          publisher: "Proceedings of Internet of Things 2010 International Conference (IoT 2010). Tokyo, Japan",
          date: "November 2010"
        },
        "Y.4409-Y.2070": {
          href: "https://www.itu.int/rec/T-REC-Y.2070-201501-I",
          title: "ITU-T Rec. Y.4409/Y.2070 (01/2015) Requirements and architecture of the home energy management system and home network services ",
          publisher: "ITU-T",
          status: "Recommendation",
          date: "January 2015"
        },
        "ISO-IEC-2382": {
          href: "https://www.iso.org/obp/ui/#iso:std:iso-iec:2382:ed-1:v2:en",
          title: "Information technology — Vocabulary",
          publisher: "ISO",
          date: "2015"
        },
        "ISO-IEC-27000": {
          href: "https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en",
          title: "Information technology — Security techniques — Information security management systems — Overview and vocabulary",
          publisher: "ISO",
          date: "2018"
        },
        "ISO-IEC-29100": {
          href: "https://www.iso.org/obp/ui/#iso:std:iso-iec:29100:ed-1:v1:en",
          title: "Information technology — Security techniques — Privacy framework",
          publisher: "ISO",
          date: "2011"
        }
        , "WOT-THING-DESCRIPTION": {
          title: "Web of Things (WoT) Thing Description 1.1"
          , href: "https://www.w3.org/TR/wot-thing-description11/"
          , authors: [
            "Sebastian Kaebisch"
            , "Takuki Kamiya"
            , "Michael McCool"
            , "Victor Charpenay"
          ]
          , publisher: "W3C"
          , date: "November 2020"
        }
        , "WOT-DISCOVERY": {
          title: "Web of Things (WoT) Discovery"
          , href: "https://www.w3.org/TR/wot-discovery/"
          , authors: [
            "Andrea Cimmino"
            , "Michael McCool"
            , "Farshid Tavakolizadeh"
            , "Kunihiko Toumura"
          ]
          , publisher: "W3C"
          , date: "November 2020"
        }
        , "WOT-SECURITY": {
          title: "Web of Things (WoT) Security and Privacy Guidelines"
          , href: "https://www.w3.org/TR/wot-security/"
          //, href: "https://w3c.github.io/wot-security/"
          , authors: [
            , "Michael McCool"
            , "Elena Reshetova"
          ]
          , publisher: "W3C"
          , date: "March 2019"
        }
      }
    };
  </script>
  <style>
    a[href].internalDFN {
      color: inherit;
      border-bottom: 1px solid #99c;
      text-decoration: none;
    }

    img.wot-arch-diagram {
      max-width: 90%;
      height: auto;
    }
  </style>
</head>

<body>
  <section id="abstract">
    <p>The W3C Web of Things (WoT) enables
      interoperability across IoT platforms and application
      domains.
      The goal of the WoT is to preserve and complement existing
      IoT standards and solutions. The W3C WoT architecture is
      designed to describe what exists, and only prescribes new mechanisms
      when necessary.
    </p>
    <p>This <em>WoT Architecture</em> specification describes the abstract
      architecture for the W3C Web of Things.
      This abstract architecture is based on 
      requirements that were derived from use cases for
      multiple application domains.
      Several modular building blocks were identified whose detailed
      specifications are given in other documents.
      This document describes how these building blocks are related and work together.
      The WoT abstract architecture defines a basic conceptual
      framework that can be mapped onto a variety of concrete deployment scenarios,
      several examples of which are given.
      However, the abstract architecture described in this specification does not
      itself define concrete mechanisms or prescribe any concrete implementation.
    </p>
  </section>
  <section id="sotd">
    <p>
      This document describes an abstract architecture.
      However, there is an
      <a href="https://w3c.github.io/wot-architecture/testing/report11.html">Implementation Report</a>
      that describes a set of concrete implementations 
      following the W3C Web of Things architecture.
      It also references the other implementation
      reports for the various WoT building blocks.
    </p>
<!--
 <p>The Web of Things Working Group intends to submit this document
        for consideration as a <abbr title=
        "World Wide Web Consortium">W3C</abbr> Proposed Recommendation
        after at least the minimum CR review period has passed. However,
        before PR transition is requested, any features or assertions
        currently marked as at-risk that did not appear in the Architecture 1.0
        specification and do not have at least two implementations at that
        time will either be removed or converted into informative
        statements, as appropriate. 
    </p>
-->
  <p class="at-risk">At-risk assertions are marked with yellow highlighting.</span></p>
  </section>
  <section id="introduction" class="informative">
    <h1>Introduction</h1>
    <p>The goals of the <em>Web of Things</em> (WoT) are to improve the interoperability
      and usability of the Internet of Things (IoT). Through a collaboration
      involving many stakeholders over many years, several building
      blocks have been identified that help address these challenges.
    </p>
    <p>A set of over 30 WoT <em>use cases</em> were contributed by stakeholders from multiple industries for various
      application domains.
      These have been collected and were published in the <em>WoT Use Cases and Requirements</em>
      <a href="https://www.w3.org/TR/wot-usecases/">https://www.w3.org/TR/wot-usecases/</a> document.
    </p>
    <p>
      The collection of use cases is classified into two categories:
    </p>
    <ul>
      <li>Horizontal use cases that address multiple domains</li>
      <li>Domain specific (vertical) use cases for a single application domain</li>
    </ul>
    <p>These use cases and requirements drive the creation and further evolution
      of the W3C WoT specification family.</p>

      <p>The WoT architecture specification is focused on the scope of W3C WoT standardization,
      which can be broken down into these building blocks as well as the abstract
      architecture that defines how they are related.
      <p>
        The architecture document serves multiple purposes:
      </p>
      <p>
      The building blocks are defined and described in detail in separate specifications.
      In addition to defining the abstract architecture and its terminology and
      conceptual framework,
      this specification also serves as an introduction to the WoT building blocks,
      and explains their interworking:</p>
    <ul>
      <li>The <em>Web of Things (WoT) Thing Description</em> [[?WOT-THING-DESCRIPTION]]
        normatively provides a machine-readable
        data format for describing the metadata and network-facing interfaces of Things.
        It is based upon the fundamental concepts introduced in this document, such as
        interaction affordances.
      </li>
      <li>The <em>Web of Things (WoT) Binding Templates</em> [[?WOT-BINDING-TEMPLATES]]
        provides informational guidelines on how to define network-facing interfaces in Things for
        particular protocols and IoT ecosystems, which we call Protocol Bindings.
        The document also provides examples for a number of existing IoT
        ecosystems and standards.
      </li>
      <li>The <em>Web of Things (WoT) Discovery</em> [[?WOT-DISCOVERY]]
        specification defines a distribution mechanism for WoT metadata 
        (<a>Thing Descriptions</a>).
	      The WoT Discovery process uses existing mechanisms for first
        contact, but provides for access control before serving detailed metadata.
        It includes support for directories and self-description.
      </li>
      <li>The <em>Web of Things (WoT) Scripting API</em> [[?WOT-SCRIPTING-API]],
        which is optional, enables the implementation of
        the application logic of a Thing using a common JavaScript API
        similar to the Web browser APIs. This simplifies IoT application
        development and enables portability across vendors and devices.
      </li>
      <li>The <em>Web of Things (WoT) Security and Privacy Guidelines</em> [[?WOT-SECURITY]]
        represent a cross-cutting building block.
        This informational document provides guidelines for the secure implementation and
        configuration of Things,
        and discusses issues which should be considered in any systems implementing W3C WoT.
        However, it should be emphasized that
        security and privacy can only be fully evaluated in the context
        of a complete set of concrete mechanisms for a specific implementation,
        which goes beyond the scope of the WoT abstract architecture.
        This is especially
        true when the WoT architecture is used descriptively for pre-existing systems,
        since the W3C WoT cannot constrain the behavior of such systems, it can only
        describe them.
        In this document we also discuss privacy and security risks and their mitigation
        at a high level in sections <a href="#sec-security-considerations"></a>
        and <a href="#sec-privacy-considerations"></a>.
      </li>
    </ul>
    <p>This specification also covers non-normative architectural aspects
      and conditions for the deployment of WoT systems.
      These guidelines are described in the context of example deployment scenarios,
      although this specification does not require specific concrete
      implementations.
    </p>
    <p>This specification serves as an umbrella for W3C WoT
      specifications and defines the basics such as terminology
      and the underlying abstract architecture of the W3C Web of
      Things. In summary, the purpose of this specification is to
      provide:</p>
    <ul>
      <li>a set of application domains in <a href="#sec-application-domains"></a>
        that were considered to identify use cases for the W3C WoT Architecture,
      </li>
      <li>a set of common deployment patterns in
        <a href="#sec-common-deployment-patterns"></a>,
      </li>
      <li>a definition of the abstract architecture in
        <a href="#sec-wot-architecture"></a>,
      </li>
      <li>an overview of a set of WoT building blocks
        and their interplay in <a href="#sec-building-blocks"></a>,
      </li>
      <li>an informative guideline on how to map the abstract architecture to
        concrete implementations in
        <a href="#sec-servient-implementation"></a>,
      </li>
      <li>informative examples of deployment scenarios in 
        <a href="#sec-deployment-scenario"></a>,
      </li>
      <li>and a set of high level
        security and privacy considerations to be aware of when
        implementing a system based on the W3C WoT architecture in
        <a href="#sec-security-considerations"></a> and
        <a href="#sec-privacy-considerations"></a>, respectively.
      </li>
    </ul>
    <p>Additional requirements, use cases, conceptual features and new building blocks
      are collected in future versions of the <em>WoT Use Cases and Requirement </em>
      <a href="https://www.w3.org/TR/wot-usecases/">https://www.w3.org/TR/wot-usecases/</a> document.
    </p>
    </section> 
    <section id="conformance"></section>
    <section id="terminology" class="informative">
    <h1>Terminology</h1>

    <p>This specification uses the following terms as defined here.
      The WoT prefix is used to avoid ambiguity for terms that are
      (re)defined specifically for Web of Things concepts.</p>
    <p>
      In case of a conflict of a definition with terminology used in another
      WoT document, the definition of the WoT Architecture takes precedence.
    </p>
    <dl>
      <dt>
        <dfn>Action</dfn>
      </dt>
      <dd>An Interaction Affordance that allows to invoke a
        function of the Thing, which manipulates state
        (e.g., toggling a lamp on or off)
        or triggers a process on the Thing (e.g., dim a lamp over time).</dd>
      <dt>
        <dfn data-lt="WoT Anonymous Thing Description" class="lint-ignore">Anonymous TD</dfn>
      </dt>
      <dd>A Thing Description without a user-defined identifier (`id` attribute).</dd>
      <dt>
        <dfn>Connected Device</dfn>
      </dt>
      <dd>
      A synonym for <a>Device</a>.</dd>
      <dt>
        <dfn data-lt="WoT Binding Templates">Binding
          Templates</dfn>
      </dt>
      <dd>
        A re-usable collection of blueprints that enable a Thing Description 
        to be used with a specific protocol, data payload format or an IoT 
        platform that combine both of them in specific ways. This is done through
        additional descriptive vocabularies, Thing Models and examples that aim 
        to guide the implementers of Things and Consumers alike. </dd>
      <dt>
        <dfn>Consumed Thing</dfn>
      </dt>
      <dd>A software abstraction that represents a remote
        Thing used by the local application. The abstraction might be
        created by a native WoT Runtime, or instantiated
        as an object through the WoT Scripting API.</dd>
        <dt>
          <dfn>Content Type</dfn>
        </dt>
        <dd>Identifier for the format of the message body. 
          Also known as media type and MIME type [[RFC2046]]. </dd>
      <dt>
        <dfn class="lint-ignore">Consuming a Thing</dfn>
      </dt>
      <dd>To parse and process a TD document and from it create a Consumed
        Thing software abstraction as interface for the application in the local
        runtime environment.</dd>
      <dt>
        <dfn>Consumer</dfn>
      </dt>
      <dd>An entity that can process WoT Thing Descriptions
        (including its JSON-based representation format)
        and interact with Things (i.e., consume Things).</dd>
      <dt>
        <dfn>Data Schema</dfn>
      </dt>
      <dd>A data schema describes the information model and the related payload structure
        and corresponding data items that are passed between <a>Things</a>
        and <a>Consumers</a> during interactions.</dd>
      <dt>
        <dfn>Device</dfn>
      </dt>
      <dd>A Device is a physical entity that has a network interface.
      Devices can be described by a <a>Thing Description</a> and are a kind of <a>Thing</a>.
      A synonym for <a>Connected Device</a>.
      Compare with <a>Service</a>.</dd>
      <dt>
        <dfn>Digital Twin</dfn>
      </dt>
      <dd>A digital twin is type of <a>Virtual Thing</a>
        that resides on a cloud or edge node. 
	Digital Twins may be used to represent and provide 
	a network interface for
        real-world devices which may not be continuously online
	(see also <a>Shadows</a>),
        may be able to run simulations of new applications and services
        before they get deployed to the real devices,
	may be able to maintain a history of past state or behaviour, 
	and may be able to predict future state or behaviour.
	Digital Twins typically have more functionality than
	simple <a>Shadows</a>.
      </dd>
      <dt>
        <dfn class="lint-ignore">Directory</dfn>
      </dt>
      <dd>A <a>Service</a> that maintains a set of data or metadata describing other <a>Services</a>
       or <a>Things</a>.  An example would be a <a>WoT Thing Description Directory</a>.</dd>
      <dt><dfn data-lt="WoT Discovery">Discovery</dfn>
      <dd>Mechanisms defined by WoT for distributing and accessing
        <a>WoT Thing Descriptions</a> on the network, 
        either locally or remotely.</dd>
      <dt>
        <dfn data-lt="WoT Discoverer" class="lint-ignore">Discoverer</dfn>
      </dt>
      <dd>An entity which acts as a client of a WoT Discovery process to discover 
        and fetch a <a>Thing Description</a>, 
        e.g. by being introduced to and searching a 
        <a>Thing Description Directory</a> exploration service or by
        fetching a <a>Thing Description</a> directly from 
        the well-known endpoint on a Thing.
      </dd>
      <dt>
        <dfn>Domain-specific Vocabulary</dfn>
      </dt>
      <dd>Linked Data vocabulary that can be used in the WoT
        Thing Description, but is not defined by W3C WoT.</dd>
      <dt>
        <dfn>Edge Device</dfn>
      </dt>
      <dd>A device that provides an entry point into
        enterprise or service provider core networks. Examples
        include hubs, gateways, routers, switches, multiplexers, and a
        variety of other access devices.</dd>
      <dt>
        <dfn data-lt="WoT Enriched Thing Description" class="lint-ignore">Enriched TD</dfn>
      </dt>
      <dd>A Thing Description embedded with additional attributes
        for bookkeeping and discovery.</dd>
      <dt>
        <dfn>Event</dfn>
      </dt>
      <dd>An Interaction Affordance that describes an event source,
        which asynchronously pushes event data to Consumers
        (e.g., overheating alerts).</dd>
      <dt>
        <dfn data-lt="WoT Exploration">Exploration</dfn>
      </dt>
      <dd>A discovery mechanism that provides access to detailed metadata in the 
        form of one or more Thing Descriptions.  Exploration mechanisms are in
        general protected by security mechanism and are accessible only to authorized users.
      </dd>
      <dt>
        <dfn>Exposed Thing</dfn>
      </dt>
      <dd>A software abstraction that represents a locally hosted Thing
        that can be accessed over the network by remote Consumers.
        The abstraction might be created by a native WoT Runtime,
        or instantiated as an object through the WoT Scripting API.</dd>
      <dt>
        <dfn class="lint-ignore">Exposing a Thing</dfn>
      </dt>
      <dd>To create an Exposed Thing software abstraction in the
        local runtime environment to manage the state of a Thing
        and interface with the behavior implementation.</dd>
      <dt>
        <dfn>Hypermedia Control</dfn>
      </dt>
      <dd>A serialization of a Protocol Binding in hypermedia, that is,
        either a Web link [[RFC8288]] for navigation or a Web form for
        performing other operations. Forms can be seen as request templates
        provided by the Thing to be completed and sent by the Consumer.</dd>
      <dt>
        <dfn>Interaction Affordance</dfn>
      </dt>
      <dd>
        Metadata of a Thing that shows and describes the possible choices to Consumers,
        thereby suggesting how Consumers may interact with the Thing.
        There are many types of potential affordances, but
        W3C WoT defines three types of Interaction Affordances:
        Properties, Actions, and Events.
        A fourth Interaction Affordance is navigation, which is already available on the Web through linking.</dd>
      <dt>
        <dfn>Interaction Model</dfn>
      </dt>
      <dd>An intermediate abstraction that formalizes and narrows the
        mapping from application intent to concrete protocol operations.
        In W3C WoT, the defined set of Interaction Affordances constitutes the Interaction Model.</dd>
      <dt>
        <dfn>Intermediary</dfn>
      </dt>
      <dd>An entity between Consumers and Things that can proxy, augment, or compose Things
        and republish a WoT Thing Description that points to the WoT Interface on the Intermediary instead of the
        original Thing.
        For Consumers, an Intermediary may be indistinguishable from a Thing, following the Layered System constraint of
        REST.</dd>
      <dt>
        <dfn data-lt="WoT Introduction">Introduction</dfn>
      </dt>
      <dd>A "first contact" discovery mechanism, whose result is a URL that
        references an exploration mechanism.  Introduction mechanisms themselves
        should not directly provide metadata, and in general are designed to be 
        open.
      </dd>
      <dt>
        <dfn>IoT Platform</dfn>
      </dt>
      <dd>A specific IoT ecosystem such as OCF, oneM2M, or
        Mozilla Project Things with its own specifications for
        application-facing APIs, data model, and protocols or
        protocol configurations.</dd>
      <dt>
        <dfn class="lint-ignore">Metadata</dfn>
      </dt>
      <dd>Data that provides a description of an entity's abstract characteristics.
        For example, a <a>Thing Description</a> is Metadata for a <a>Thing</a>.</dd>
      <dt>
        <dfn data-lt="Personally Identifiable Information">Personally Identifiable Information (PII)</dfn>
      </dt>
      <dd>
        Any information that can be used to identify the natural person to whom such information relates,
        or is or might be directly or indirectly linked to a natural person.
        We use the same definition as [[ISO-IEC-29100]].
      </dd>
      <dt>
        <dfn class="lint-ignore">Orchestration</dfn>
      </dt>
      <dd>
        The automation of the behavior of a collection of things. 
        Orchestration is combining individual things with rules or services
        into a new service or virtual <a>Thing</a>.
      </dd>
      <dt>
        <dfn>Partial TD</dfn>
      </dt>
      <dd>
        A <a>Partial TD</a> is an object that follows the same hierarchical structure of the <a>TD</a> information model, 
        but it is not required to contain all the mandatory elements. 
        <p>
          Note: An example for the usage of a <a>Partial TD</a> is in <a>WoT Scripting API</a>, 
          where it is used as input for the creation of <a>Exposed Things</a>. 
        </p></dd>
      <dt>
        <dfn class="lint-ignore">Privacy</dfn>
      </dt>
      <dd>Freedom from intrusion into the private life or affairs of an individual when that intrusion results from
        undue or illegal gathering and use of data about that individual.
        We use the same definition as [[ISO-IEC-2382]].
        See also <a>Personally Identifiable Information</a> and <a>Security</a>,
        as well as other related definitions in [[ISO-IEC-29100]].
      </dd>
      <dt>
        <dfn>Private Security Data</dfn>
      </dt>
      <dd>
        Private Security Data is that component of a Thing's <a>Security Configuration</a> that is
        kept secret and is not shared with other devices or users. An example would be private keys in a PKI
        system. Ideally such data is stored in a separate memory inaccessible to the application
        and is only used via abstract operations, such as signing, that do not reveal the secret
        information even to the application using it.</dd>
      <dt>
        <dfn>Producer</dfn>
      </dt>
      <dd>An entity that can create WoT Thing Descriptions
        for a specific Thing.</dd>
      <dt>
        <dfn>Profile</dfn>
      </dt>
      <dd>A technical specification which provides a set of assertions such that any <a>Consumer</a> 
	which conforms with the those assertions is out-of-the-box interoperable with any <a>Thing</a> 
	which also conforms with those assertions.
      </dd>
      <dt>
        <dfn>Property</dfn>
      </dt>
      <dd>An Interaction Affordance that exposes state of the Thing.
        This state can then be retrieved (read) and optionally updated (write).
        Things can also choose to make Properties observable by notifying <a>Consumers</a>
        about a state change.</dd>
      <dt>
        <dfn data-lt="WoT Protocol Binding">Protocol Binding</dfn>
      </dt>
      <dd>The mapping from an Interaction Affordance to concrete messages of a specific protocol,
        thereby informing <a>Consumers</a> how to activate the <a>Interaction Affordance</a>.
        W3C WoT serializes Protocol Bindings as <a>hypermedia controls</a>.</dd>
      <dt>
        <dfn>Public Security Metadata</dfn>
      </dt>
      <dd>
        Public Security Metadata is that component of a Thing's <a>Security Configuration</a> which
        describes the security mechanisms and access rights necessary to access a Thing.
        It does not include any secret information or concrete data (including public keys), and does
        not by itself, provide access to the Thing. Instead, it describes the mechanisms by which access
        may be obtained by authorized users, including how they must authenticate themselves.
      </dd>
      <dt>
        <dfn data-lt="WoT Registrant" class="lint-ignore">Registrant</dfn>
      </dt>
      <dd>An entity which registers a <a>Thing Description</a>
        with a <a>Thing Description Directory</a>. 
        This entity may or may not be the <a>Thing</a> that
        the registered <a>Thing Description</a> describes.
      </dd>
      <dt>
        <dfn>Security</dfn>
      </dt>
      <dd>Preservation of the confidentiality, integrity and availability of information.
        Properties such as authenticity, accountability, non-repudiation, and reliability may also be involved.
        This definition is adapted from the definition of <i>Information Security</i> in [[ISO-IEC-27000]], which
        also includes additional definitions of each of the more specific properties mentioned.
        Please refer to this document for other related definitions.
        We additionally note that it is desirable that these properties be maintained both in normal operation
        and when the system is subject to attack.
      </dd>
      <dt>
        <dfn>Security Configuration</dfn>
      </dt>
      <dd>The combination of Public Security Metadata, Private Security Data, and any other configuration
        information (such as public keys) necessary to operationally configure the security mechanisms of a Thing.</dd>
      <dt>
        <dfn>Service</dfn>
      </dt>
      <dd>A Service is a software entity that has a network interface.
      Services can be described by a <a>Thing Description</a> and are a kind of <a>Thing</a>.
      See also <a>Virtual Thing</a>.
      Compare with <a>Device</a>.</dd>
      <dt>
        <dfn>Servient</dfn>
      </dt>
      <dd>A software stack that implements the WoT building
        blocks. A Servient can host and expose Things and/or host Consumers that consume Things.
        Servients can support multiple Protocol Bindings to enable
        interaction with different IoT platforms.</dd>
      <dt>
        <dfn>Shadow</dfn>
      </dt>
      <dd>A Shadow is a <a>Virtual Thing</a> that
      maintains a copy of the state and mediates interactions with another
      <a>Thing</a>.
      A Shadow aims to achieve eventual consistency with the state
      of the Thing it represents.
      If a Shadow has more functionality than simply mirroring state
      it may be better to refer to it as a <a>Digital Twin</a>.
      </dd>
      <dt>
        <dfn>Subprotocol</dfn>
      </dt>
      <dd>An extension mechanism to a transport protocol that
        must be known to interact successfully.
        An example is long polling for HTTP.</dd>
      <dt>
        <dfn class="lint-ignore">System</dfn>
      </dt>
      <dd>An entity consisting of multiple interacting components.</dd>
      <dt>
        <dfn>TD</dfn>
      </dt>
      <dd>Short for <a>WoT Thing Description</a>.</dd>
      <dt>
        <dfn>TDD</dfn>
      </dt>
      <dd>Short for <a>WoT Thing Description Directory</a>.</dd>
      <dt>
        <dfn class="lint-ignore">TD Vocabulary</dfn>
      </dt>
      <dd>A Linked Data vocabulary controlled by W3C WoT to
        tag the metadata of Things in the WoT Thing Description
        including communication metadata of WoT Binding
        Templates.</dd>
      <dt>
        <dfn class="lint-ignore">TD Context Extension</dfn>
      </dt>
      <dd>A mechanism to extend <a>Thing Descriptions</a> with additional <a>Vocabulary
        Terms</a> using <code>@context</code> as specified in JSON-LD[[?JSON-LD11]]. 
        It is the basis for semantic annotations and extensions to core
      mechanisms such as Protocol Bindings, Security Schemes, and Data Schemas.</dd>
      <dt>
        <dfn class="lint-ignore">TD Server</dfn>
      </dt>
      <dd>Short for <a>Thing Description Server</a>.</dd>
      <dt>
        <dfn>Thing</dfn> or <dfn>Web Thing</dfn>
      </dt>
      <dd>An abstraction of a physical or a virtual entity
        whose metadata and interfaces are described by a WoT
        Thing Description, whereas a virtual entity is the
        composition of one or more Things.</dd>
      <dt>
        <dfn data-lt="WoT Thing Description Directory">Thing Description Directory</dfn> 
      </dt>
      <dd>A directory service for TDs that provides a Web
        interface to register TDs and look them up
        (e.g., using JSONPath or SPARQL queries).
        A recommended API and feature set is defined in [[WOT-DISCOVERY]], and is
        used as an optional part of the <a>WoT Discovery</a> process.
      </dd>
      <dt>
        <dfn>TD Fragment</dfn>
      </dt>
      <dd>
        A <a>TD Fragment</a> is a substructure of the data model of a TD.
        It is a valid object structure that can be validated syntactically against a part of the TD information model 
	      defined in chapter 5 of the <a>Thing Description</a>specification, however the fragment may omit some context that allows full validation.
      </dd>
      <dt>
        <dfn data-lt="WoT Thing Description Server">Thing Description Server</dfn> 
      </dt>
      <dd>A Thing Description Server is a web resource, addressed by a URL, that can provide
        a Thing Description when accessed.
        Its requirements are defined in [[WOT-DISCOVERY]], and is
        used as an optional part of the <a>WoT Discovery</a> process.
      </dd>
      <dt>
        <dfn data-lt="WoT Thing Model">Thing Model</dfn>
      </dt>
      <dd>A <a>Thing Model</a> is a description for a class of Things that have the same 
        capabilities. It describes the <a>Properties</a>, <a>Actions</a>, and <a>Events</a> and common metadata that are 
        shared for an entire group of <a>Things</a>. Compared to a Thing Description, a Thing Model does not contain enough 
        information to identify or interact with a Thing instance.</dd>
      <dt>
        <dfn>Transport Protocol</dfn>
      </dt>
      <dd>The underlying, standardized application layer
        protocol without application-specific requirements or
        constraints on options or subprotocol mechanisms.
        Examples are HTTP, CoAP, or MQTT.
      </dd>
      <dt>
        <dfn>Trusted Environment</dfn>
      </dt>
      <dd>Set of devices that assume each other's claims of
        identity are authentic without proof and allow relatively unrestricted
        access to one another over a common protected network.
      </dd>
      <dt>
        <dfn>Virtual Thing</dfn>
      </dt>
      <dd>A <a>Service</a> that 
       represents,
       augments the functionality of,
       provides an improved interface to,
       or 
       stands in place of
       one or more other <a>Things</a>.
       A Virtual Thing will often act as an <a>Intermediary</a>.
       Examples include <a>Shadows</a> and <a>Digital Twins</a>.
      </dd>
      <dt>
        <dfn>Vocabulary</dfn>
      </dt>
      <dd>
        A collection of <a>Vocabulary Terms</a>, identified by a namespace IRI.
      </dd>
      <dt>
        <dfn>Term</dfn>
        and
        <dfn>Vocabulary Term</dfn>
      </dt>
      <dd>
        A character string. When a <a>Term</a> is part of a <a>Vocabulary</a>, i.e., prefixed by
        a namespace IRI[[RFC3987]], it is called a <a>Vocabulary Term</a>. For the sake of readability,
        <a>Vocabulary Terms</a> present in this document are always written in a compact
        form and not as full IRIs.
      </dd>
      <dt>
        <dfn>WoT Interface</dfn>
      </dt>
      <dd>The network-facing interface of a Thing
        that is described by a WoT Thing Description.</dd>
      <dt>
        <dfn>WoT Profile</dfn>
      </dt>
	<dd>Synonym for <a>Profile</a></dd>	    
      <dt>
        <dfn>WoT Runtime</dfn>
      </dt>
      <dd>A runtime system that maintains an execution
        environment for applications, and is able to expose and/or
        consume Things, to process WoT Thing Descriptions, to maintain Security
        Configurations, and to interface with Protocol Binding implementations.
        A WoT Runtime may have a custom API or use the optional WoT Scripting API.</dd>
      <dt>
        <dfn>WoT Scripting API</dfn>
      </dt>
      <dd>The application-facing programming interface
        provided by a Servient in order to ease
        the implementation of behavior or applications running in a WoT
        Runtime. It is comparable to the Web browser APIs.
        The WoT Scripting API is an optional building block for W3C WoT.</dd>
      <dt>
        <dfn class="lint-ignore">WoT Servient</dfn>
      </dt>
      <dd>Synonym for Servient.</dd>
      <dt>
        <dfn>WoT Thing Description</dfn> or <dfn>Thing Description</dfn>
      </dt>
      <dd>Structured data describing a Thing. A WoT Thing Description comprises
        general metadata, domain-specific metadata, Interaction Affordances
        (which include the supported Protocol Bindings), and links to related Things.
        The WoT Thing Description format is the central building block of W3C WoT.</dd>
    </dl>

    <!-- Device categories -->
    <section id="device-categories">
      <h2>Device Categories</h2>	  
      <p>
        In a deployment of WoT conforming to the <a href="https://www.w3.org/TR/wot-architecture/#architecture-abstract">WoT Abstract Architecture</a>
        we see a variety of different device types.
        They range (sorted in the order of footprint and capabilities) 
        from small embedded <em>node</em> devices to <em>gateways</em> or <em>hubs</em> 
        to powerful <em>edge</em> devices and <em>cloud</em> servers.
        Interoperability between these devices implies that a core set of features and functionalities
        is available on <em>all</em> of them.
      </p>
      
      <p> 
        The following device categories describe the footprint and characteristics of 
        typical representatives of these classes.
        This is used to identify the possible features and use cases for these device classes.
      </p>
      
      <p> 
        These categories are aligned with the classes defined by the IETF [[RFC7228]] for constrained devices,
        however the classes have been extended to larger devices and 
        bounds on typical sizes of RAM and Flash/ROM are provided.  
        Memory and storage size are both easier to quantify and more limiting than performance, 
        so that is the basis of this categorization.
        This is not a strict categorization.
        Categories may overlap and not all memory may be available for user applications.
      </p>
      
      <table class="def">
      <tr>
        <th>Category</th> 
        <th>data size (RAM)</th>
        <th>code size (Flash, ROM, ...)</th>
        <th>Typical Representative</th>
        <th>Remarks, typical application scenarios</th>
      </tr>  
      <tr>
        <td>Class-0, C0</td>
        <td>&lt;&lt; 10 KiB</td>
        <td>&lt;&lt; 100 KiB</td>
        <td>small footprint microcontrollers</td>
        <td>Sensor nodes without secure communication</td>
      </tr>
      <tr>
        <td>Class-1, C1</td>
        <td>~ 10 KiB</td>
        <td>~ 100 KiB</td>
        <td>microcontrollers</td> <!-- could just call this a "node" or "basic node" -->
        <td>Sensors that typically supports secure communication protocols such as TLS, DTLS</td>
      </tr><tr>
        <td>Class-2, C2</td>
        <td>~ 64 KiB</td>
        <td>~ 256 KiB</td>
        <td>connected limited device</td> 
        <td>Small embedded devices such as M2M communication nodes, smart meters, sensor nodes and other embedded appliances, 
          home appliances, low-end TV set-top boxes, and point of sale terminals are some examples.</td>
        <!-- could just call this an "advanced node" or just a "node" if above is "basic node" -->
      </tr><tr>
        <td>Class-3, C3</td>
        <td>~ 64-256 KiB</td>
        <td>~ 256 KiB - several MBs</td>
        <td>ISP gateway</td>
        <td>Small home and industrial gateways</td>
      </tr><tr>
        <td>Class-4, C4</td>
        <td>~  256 KiB -  several MB</td>
        <td>~  1 MB - several MB</td>
        <td>gateway/hub</td>
        <td>Large home and industrial gateways</td>
      </tr><tr>
        <td>Class-5, C5</td>
        <td>~ 1 - 8 GB</td>
        <td>~ 1 - 16 GB</td>
        <td>edge</td>
        <td>Small edge servers</td>
      </tr><tr>
        <td>Class-6, C6</td>
        <td>~ several GB</td>
        <td>~ several GB</td>
        <td>edge</td>
        <td>Large edge servers</td>
      </tr>
      <tr>
        <td>Class-7, C7</td>
        <td>~ several GB</td>
        <td>~ several GB</td>
        <td>cloud</td>
        <td>Cloud systems with multiple compute nodes</td>
      </tr></table>

      <p class="note" title="Category Borders">
      Category borders are soft borders and categories are not exclusive, 
      i.e. there are application scenarios that 
      can be implemented by devices from several categories.
      For secure communications we consider devices that support TLS/HTTP, DTLS/CoAP, 
      and similar secure protocols.
      </p>
    </section>
  </section>

  <section id="sec-application-domains" class="informative">
    <h2>Application Domains</h2>
    <p>
      This section presents the application domains
      targeted by the W3C WoT and which are used to derive the
      abstract architecture discussed in <a href="#sec-building-blocks"></a>.
    </p>
    <p>These application domains are motivated by the use cases 
      that are described in [[?WOT-USE-CASES-REQUIREMENTS]].</p>
    <p>The Web of Things architecture does not put any
      limitations on use cases and application domains. Various
      application domains have been considered to collect common
      patterns that have to be satisfied by the abstract
      architecture.</p>
    <p>The following sections are not exhaustive. Rather they
      serve as illustrations, where connected things can provide
      additional benefit or enable new scenarios.</p>

    <section id="consumer-use-cases">
      <h3>Consumer</h3>
      <p>In the consumer space there are multiple assets
        that benefit from being connected. Lights and air
        conditioners can be turned off based on room
        occupancy. Window blinds can be closed automatically
        based on weather conditions and presence. Energy and
        other resource consumption can be optimized based on
        usage patterns and predictions.</p>
      <p>The consumer scenario in this section describes the
        Smart Home use case.</p>
      <p>
        <a href="#smart-home"></a> shows an example of a
        Smart Home. In this case, gateways are connected to
        edge devices such as sensors, cameras and home
        appliances through corresponding local communication
        protocols such as KNX, ECHONET, ZigBee, DECT ULE and
        Wi-SUN. Multiple gateways can exist in one home,
        while each gateway can support multiple local
        protocols.
      </p>
      <p>Gateways can be connected to the cloud through
        the internet, while some appliances can be connected
        to the cloud directly. Services running in the cloud
        collect data from edge devices and analyze the data,
        then provide value to users through the edge devices
        and other UX devices.</p>
      <figure id="smart-home">
        <img src="images/wot-use-cases/smart-home.png" srcset="images/wot-use-cases/smart-home.svg"
          class="wot-arch-diagram" alt="smart home use case" />
        <figcaption>Smart Home</figcaption>
      </figure>
      <p>Smart home provides consumer benefits such as
        remote access and control, voice control and home
        automation. Smart home also enables device
        manufacturers to monitor and maintain devices
        remotely. Smart home can realize value added
        services such as energy management and security
        surveillance.</p>
    </section>
    <section id="industrial-iot-usecases">
      <h3>Industrial</h3>
      <p>
        The industrial use cases in this section are
        applicable to different industry verticals. <br />
        Due to the nature of overlaps in the application
        scenarios, different verticals have similar use
        cases.
      </p>
      <section>
        <h4>Example: Smart Factory</h4>
        <p>
          <a href="#smart-factory"></a> shows an example
          of a Smart Factory. In this case, field-level,
          cell and line controllers automate different
          factory equipment based on industrial
          communication protocols such as PROFINET,
          Modbus, OPC UA TSN, EtherCAT, or CAN. An
          industrial edge device collects selected data
          from various controllers and makes it available
          to a cloud backend service, e.g., for remote
          monitoring via a dashboard or analyzes it for
          preventive maintenance.
        </p>
        <figure id="smart-factory">
          <img src="images/wot-use-cases/smart_factory_new.png" srcset="images/wot-use-cases/smart_factory_new.svg"
            class="wot-arch-diagram" alt="smart factory use case" />
          <figcaption>Smart Factory</figcaption>
        </figure>
      </section>
      <p>Smart factories require advanced monitoring of
        the connected manufacturing equipment as well of the
        manufactured products. They benefit from predictions
        of machine failures and early discovery of anomalies
        to prevent costly downtime and maintenance efforts.</p>
      <p>Additionally, monitoring of connected
        manufacturing equipment and the environment at the
        production facility for the presence of poisonous
        gases, excessive noise or heat increases the safety
        of the workers and reduces the risks of incidents or
        accidents.</p>
      <p>Real-time monitoring and KPI calculations of
        production equipment helps to detect productivity
        problems and optimize the supply chain.</p>
    </section>
    <section id="sec-transportationlogistics">
      <h4 id="transportationlogistics">Transportation
        &amp; Logistics</h4>
      <p>Monitoring of vehicles, fuel costs, maintenance
        needs and assignments helps to optimize the full
        utilization of the vehicle fleet.</p>
      <p>Shipments can be tracked to be en-route to ensure
        consistent quality and condition of the transported
        goods. This is especially useful to assert the
        integrity of the cold-chain from warehouses to
        refrigerated trucks to delivery.</p>
      <p>Centralized monitoring and management of stock in
        warehouses and yards can prevent out of stock and
        excessive stock situations.</p>
    </section>
    <section id="sec-utilities">
      <h4 id="utilities">Utilities</h4>
      <p>Automated reading of residential and C&amp;I
        (Commercial and Industrial) meters, and billing
        offers continuous insights into resource consumption
        and potential bottlenecks.</p>
      <p>Monitoring the condition and output of
        distributed renewable energy generation equipment
        enables optimization of distributed energy
        resources.</p>
      <p>Monitoring and remote-controlling of distribution
        equipment helps to automate the distribution
        process.</p>
      <p>Continuous monitoring of generation and
        distribution infrastructure is improving safety of
        utilities crew in the field.</p>
    </section>
    <section id="sec-oilandgas">
      <h4 id="oilandgas">Oil and Gas</h4>
      <p>Offshore platform monitoring, leakage detection
        and prediction of pipelines as well as monitoring
        and controlling the levels in tanks and reservoirs
        helps to improve the industrial safety for the
        workforce as well as for the environment.</p>
      <p>Automated calculation of a distributed stock
        through various storage tanks and delivery
        pipes/trucks allows for improved planning and
        resource optimization.</p>
    </section>
    <section id="sec-insurance">
      <h4 id="insurance">Insurance</h4>
      <p>Proactive Asset Monitoring of high value assets
        such as connected structures, fleet vehicles, etc.
        mitigates the risk of severe damage and high costs
        due to predictions and early detection of incidents.</p>
      <p>Usage based insurance can be offered with usage
        tracking and customized insurance policies.</p>
      <p>Predictive weather monitoring and re-routing
        fleet vehicles to covered garages can limit loss due
        to hail damage, tree damage.</p>
    </section>
    <section id="sec-engineering-and-construction">
      <h4 id="engineering-and-construction">Engineering
        and Construction</h4>
      <p>Monitoring for industrial safety reduces the
        risks of security hazards. Monitoring of assets at
        construction site can prevent damage and loss.</p>
    </section>

    <section id="sec-agriculture">
      <h3 id="agriculture">Agriculture</h3>
      <p>Soil condition monitoring and creating optimal
        plans for watering, fertilizing as well as
        monitoring the produce conditions optimize the
        quality and output of agricultural produce.</p>
    </section>
    <section id="sec-healthcare">
      <h3 id="healthcare">Healthcare</h3>
      <p>Data collection and analytics of clinical trial
        data helps to gain insights into new areas.</p>
      <p>Remote patient monitoring mitigates the risk of
        undetected critical situations for elderly people
        and patients after hospitalization.</p>
    </section>
    <section id="sec-environmentmonitoring">
      <h3 id="environmentmonitoring">Environment
        Monitoring</h3>
      <p>Environment monitoring typically relies on a lot
        of distributed sensors that send their measurement
        data to common gateways, edge devices and cloud
        services.</p>
      <p>Monitoring of air pollution, water pollution and
        other environmental risk factors such as fine dust,
        ozone, volatile organic compound, radioactivity,
        temperature, humidity to detect critical environment
        conditions can prevent unrecoverable health or
        environment damages.</p>
    </section>
    <section id="sec-smart-cities">
      <h3 id="smartcities">Smart Cities</h3>
      <p>Monitoring of Bridges, Dams, Levees, Canals for
        material condition, deterioration, vibrations
        discovers maintenance repair work and prevents
        significant damage. Monitoring of highways and
        providing appropriate signage ensures optimized
        traffic flow.</p>
      <p>Smart Parking is optimizing and tracking the
        usage and availability of parking spaces and
        automates billing/reservations.</p>
      <p>Smart control of street lights based on presence
        detection, weather predictions, etc. reduces cost.</p>
      <p>Garbage containers can be monitored to optimize
        the waste management and the trash collection route.</p>
    </section>
    <section id="sec-smart-buildings">
      <h3 id="smartbuildings">Smart Buildings</h3>
      <p>Monitoring the energy usage throughout the
        building helps to optimize resource consumption and
        reduce waste.</p>
      <p>Monitoring the equipment in the buildings such as
        HVAC, Elevators, etc. and fixing problems early
        improves the satisfaction of occupants.</p>
    </section>
    <section id="sec-connected-car">
      <h3 id="connectedcar">Connected Car</h3>
      <p>Monitoring of operation status, prediction of
        service needs optimizes maintenance needs and costs.
        Driver safety is enhanced with notifications of an
        early warning system for critical road and traffic
        conditions.</p>
      <section id="connected-car-example">
        <h4 id="connectedcar-example">Connected Car
          Example</h4>
        <p>
          <a href="#connected-car"></a> shows an example
          of a Connected Car. In this case, a gateway
          connects to car components through CAN and to
          the car navigation system through a proprietary
          interface. Services running in the cloud collect
          data pushed from car components and analyze the
          data from multiple cars to determine traffic
          patterns. The gateway can also consume cloud
          services, in this case, to get traffic data and
          show it to the driver through the car navigation
          system.
        </p>
        <figure id="connected-car">
          <img src="images/wot-use-cases/connected-car.png" srcset="images/wot-use-cases/connected-car.svg"
            class="wot-arch-diagram" alt="connected car use case" />
          <figcaption>Connected Car</figcaption>
        </figure>
      </section>
    </section>
  </section>


  <section id="sec-common-deployment-patterns" class="informative">
    <h1>Common Deployment Patterns</h1>
    <p>
      This section introduces common deployment patterns that
      illustrate how devices/things interact with controllers,
      other devices, agents and servers.
      In this section, we use the term <em>client role</em> as an
      initiator of a transport protocol, and the term <em>server role</em>
      as a passive component of a transport protocol.
      This does not imply prescribing a specific role on any system component.
      A device can be in a <em>client</em> and <em>server</em> role simultaneously.
    </p>
    <p>
      One example of this dual role is a sensor, that registers itself with a cloud service
      and regularly sends sensor readings to the cloud.
      In the response messages the cloud can adjust the transmission rate of the
      sensor's messages or select specific sensor attributes, that are to be transmitted in future messages.
      Since the sensor registers itself with the cloud and initiates connections, it is in the 'client' role.
      However, since it also reacts to requests, that are transmitted in response messages, it also fulfills a 'server'
      role.
    </p>
    <p>
      The following sections illustrate the roles, tasks, and use case patterns with increasing complexity.
      They are not exhaustive and are presented to motivate for the WoT architecture and building blocks
      that are defined in later sections of this specification.
    </p>
    <p>
    This section also makes use of the concept of a <a>Trusted Environment</a>,
    which is a set of devices that allow relatively unrestricted
    access to one another.  This is a common approach but carries some
    risks, which are discussed in section
    <a href="#sec-security-consideration-trusted-environment-risks"></a>,
    along with mitigations of these risks.
    </p>

    <section id="telemetry">
      <h3>Telemetry</h3>  
      <p>
        Telemetry is the monitoring of remote devices, which implies automatic transmission to, and processing
        of measurements and other data on a <a>Consumer</a>. 
        Data may be transported over various communication channels, both wireless and wired.
        Examples include GSM networks, Bluetooth, WiFi, Ethernet, and other wired standards.
      </p>
      <p>
        Remote metering devices include one or multiple sensors, in some cases they also contain an actuator.
        In many cases the sensor data is transmitted at regular intervals, on a state change, 
        or as a response to a request by the <a>Consumer</a>.
      </p><p>
        Remote metering devices are frequently small embedded systems with very limited resources,
        i.e. Class-2 or below. 
        They may be battery powered and have to minimize power consumption through various measures,
        e.g. sleep modes.
        These devices will sleep most of the time and won't transmit any data to conserve energy.
        They only wake up on certain events (e.g. when a switch is toggled).
        When a device state changes, an event is sent to the consumer. 
        After that the devices goes to sleep mode again.
      </p>
      <p>
        Typical user scenarios are monitoring of various assets, examples include smart cities, 
        factories, fleets, environmental monitoring and health monitoring. 
        Some deployments may require monitoring of a high number of geographically distributed assets,
        others only include a few devices, as in a smart home.
        A common pattern is the one-to-many relationship between a single <a>Consumer</a> and multiple devices (<a>Things</a>).
      </p>
    </section>

    <section id="device-controllers">
      <h3>Device Controllers</h3>
      <p>
        A common deployment pattern is a local device controlled by a
        user-operated remote controller as depicted in <a href="#smart-home-device"></a>. 
      </p>
      <p>
        A remote controller can access an electronic appliance
        through the local home network directly. In this
        case, the remote controller can be implemented by a
        browser or native application.
      </p>
      <p>In this pattern, at least one device like the
        electronic appliance has a server role that can
        accept a request from the other devices and responds
        to them, and sometimes initiates a mechanical
        action. The other device like the remote controller
        has a client role that can send a message with a
        request, like to read a sensor value or to turn on
        the device.
        Moreover, to emit a current state or event notification of a device,
        the device may have a client role that can send a message
        to another device, which has server roles.
      </p>
      <figure id="smart-home-device">
        <img src="images/wot-use-cases/smart-home-device.png" srcset="images/wot-use-cases/smart-home-device.svg"
          class="wot-arch-diagram" alt="smart home device use case" />
        <figcaption>Device Control</figcaption>
      </figure>
    </section>
    <section>
      <h3>Thing-to-Thing</h3>
      <p>
        <a href="#smart-home-t2t"></a> shows an example of a
        direct Thing-to-Thing interaction. The scenario is
        as follows: a sensor detects a change of the room
        condition, for example the temperature exceeding a
        threshold, and issues a control message like "turn
        on" to the electronic appliance. The sensor unit can
        issue some trigger messages to other devices.
      </p>
      <p>In this case, when two devices that have server
        roles are connected, at least one device must have
        also a client role that issues a message to the
        other to actuate or notify.</p>
      <figure id="smart-home-t2t">
        <img src="images/wot-use-cases/smart-home-t2t.png" srcset="images/wot-use-cases/smart-home-t2t.svg"
          class="wot-arch-diagram" alt="smart home t2t deployment scenario" />
        <figcaption>Control Agent</figcaption>
      </figure>
    </section>
    <section>
      <h3>Remote Access</h3>
      <p>
        This deployment scenario contains a mobile remote controller
        (e.g., on a smartphone) as shown in <a href="#smart-home-multi"></a>. The remote
        controller can switch between different network
        connections and protocols, e.g., between a cellular
        network and a home network, which is using protocols
        such as Wi-Fi and Bluetooth. When the controller is
        in the home network it is a trusted device and no
        additional security or access control is required.
        When it is outside of the trusted network,
        additional access control and security mechanisms
        must be applied to ensure a trusted relationship.
        Note that in this scenario the network connectivity
        may change due to switching between different
        network access points or cellular base stations.
      </p>
      <p>
        In this pattern, the remote controller and the
        electronic appliance have a client and a server role
        as in the related scenario in <a href="#smart-home-device"></a>.
      </p>
      <figure id="smart-home-multi">
        <img src="images/wot-use-cases/smart-home-multi.png" srcset="images/wot-use-cases/smart-home-multi.svg"
          class="wot-arch-diagram" alt="smart home with multiple network interfaces" />
        <figcaption>Multiple Network Interfaces</figcaption>
      </figure>
    </section>
    <section>
      <h3>Smart Home Gateways</h3>
      <p>
        <a href="#smart-home-gateway"></a> shows a deployment scenario
        of a <em>Smart Home Gateway</em>. The gateway
        is placed between a home network and the Internet.
        It manages electronic appliances inside the
        house and can receive commands from a remote
        controller over the Internet, e.g., from a
        smartphone as in the previous scenario. It is also
        is a virtual representation of a device. The Smart
        Home Gateway typically offers proxy and firewall
        functionality.
      </p>
      <p>In this pattern, the home gateway has both a
        client and a server role. When the remote controller actuates the electronic appliance,
        it can connect to the
        electronic appliance in the client role and to the
        remote controller with the server role.
        When the electronic appliance emits a message to the
        remote controller, the gateway act as server roles
        for the electric appliance, and it act as client roles
        for the remote controller.
      </p>
      <figure id="smart-home-gateway">
        <img src="images/wot-use-cases/smart-home-gateway.png" srcset="images/wot-use-cases/smart-home-gateway.svg"
          class="wot-arch-diagram" alt="smart home gateway use case" />
        <figcaption>Smart Home Gateway</figcaption>
      </figure>
    </section>
    <section>
      <h3>Edge Devices</h3>
      <p>
        An <em>Edge Device</em> or <em>Edge Gateway</em> is similar to a Smart
        Home Gateway. We use the term to indicate additional
        tasks that are carried out by the edge gateway.
        Whereas the home gateway in <a href="#edge-device"></a> primarily just
        bridges between the public and the trusted network,
        the edge device has local compute capabilities and
        typically bridges between different protocols. Edge
        devices are typically used in industrial solutions,
        where they can provide preprocessing, filtering and
        aggregation of data provided by connected devices
        and sensors.
      </p>
      <figure id="edge-device">
        <img src="images/wot-use-cases/edge-device.png" srcset="images/wot-use-cases/edge-device.svg"
          class="wot-arch-diagram" alt="edge device use case" />
        <figcaption>Edge device</figcaption>
      </figure>
    </section>
    <section>
      <h3>Digital Twins</h3>
      <p>A <em>Digital Twin</em> is a virtual representation, i.e.
        a model of a device or a group of devices that
        resides on a cloud server or edge device. It can be
        used to represent real-world devices which may not
        be continuously online, or to run simulations of new
        applications and services, before they get deployed
        to the real devices.</p>
      <figure id="digital-twin">
        <img src="images/wot-use-cases/digital-twin.png" srcset="images/wot-use-cases/digital-twin.svg"
          class="wot-arch-diagram" alt="digital twin use case" />
        <figcaption>Digital Twin</figcaption>
      </figure>
      <p>Digital twins can model a single device, or they
        can aggregate multiple devices in a virtual
        representation of the combined devices.</p>
      <figure id="digital-twin-multiple-devices">
        <img src="images/wot-use-cases/digital-twin-multiple-devices.png"
          srcset="images/wot-use-cases/digital-twin-multiple-devices.svg" class="wot-arch-diagram"
          alt="digital twin multiple devices use case" />
        <figcaption>Digital Twin for Multiple
          Devices</figcaption>
      </figure>

      <p>Digital twins can be realized in different ways,
        depending on whether a device is already connected
        to the cloud, or whether it is connected to a
        gateway, which itself is connected to the cloud.</p>
      <section>
        <h4>Cloud Connected Devices</h4>
        <p>
          <a href="#smart-home-cloud1"></a> shows an
          example where electronic appliances are
          connected directly to the cloud. The cloud
          mirrors the appliances and, acting as a digital
          twin, can receive commands from remote
          controllers (e.g., a smartphone). Authorized
          controllers can be located anywhere, as the
          digital twin is globally reachable.

        </p>
        <figure id="smart-home-cloud1">
          <img src="images/wot-use-cases/smart-home-cloud1a.png" srcset="images/wot-use-cases/smart-home-cloud1a.svg"
            class="wot-arch-diagram" alt="smart home cloud use case 1" />
          <figcaption>Appliance Twin for a
            Cloud Connected Devices</figcaption>
        </figure>
      </section>

      <section id="orchestration">
        <h3>Orchestration</h3>    
        <p>Orchestration of devices and operation flows provides capabilities that go 
          beyond the simple isolated usage of a device.
          An orchestrated set of devices can provide combined operations, 
          that affect the state of multiple devices with a single operation.</p>
          <p>
          These operations combine individual operations into a combined operation flow,
          the flow may have several alternative paths, that are chosen based 
          on some device state or property values. 
        </p>
        <p>Orchestrated devices can be deployed in various topologies and can be
          connected via different networks. The system, that is built from these 
          devices, can provide capabilities, that combine and exceed the capabilities of 
          individual devices.
        </p>  
        <p>A typical orchestration example is a smart home, where various sensors 
          (temperature, occupancy, humidity, light, air quality, door sensors) are
          interworking and provide operation flows for situations like entering or leaving the house,
          morning/evening routine, adjusting light and temperature based on presence, and much more.  
        </p>  
      </section>
  
      <section>
        <h3>Legacy Devices</h3>
        <p>
          <a href="#smart-home-cloud2"></a> shows an
          example where legacy electronic appliances
          are not directly connected to the cloud. Here, a
          gateway is needed to relay the connection. The
          gateway works as:
        </p>
        <ul>
          <li>integrator of a variety of legacy
            communication protocols both in the physical
            and logical view</li>
          <li>firewall toward the Internet</li>
          <li>privacy filter which substitutes real
            image and/or speech, and logs data locally</li>
          <li>local agent in case the network
            connection is interrupted</li>
          <li>emergency services running locally when
            fire alarms and similar events occur</li>
        </ul>
        <p>The cloud mirrors the gateway with all
          connected appliances and acts as a digital twin
          that manages them in the cloud in conjunction
          with the gateway. Furthermore, the cloud can
          receive commands from remote controllers (e.g.,
          a smartphone), which can be located anywhere.</p>
        <figure id="smart-home-cloud2">
          <img src="images/wot-use-cases/smart-home-cloud2.png" srcset="images/wot-use-cases/smart-home-cloud2.svg"
            class="wot-arch-diagram" alt="smart home cloud use case 2" />
          <figcaption>A Digital Twin for a
            Legacy Device</figcaption>
        </figure>
      </section>
    </section>
    <section>
      <h3>Multi-Cloud</h3>
      <p>Typical IoT deployments consist of multiple
        (thousands) of devices. Without a standardized
        mechanism, the management of firmware updates for
        specific clouds require a lot of effort and hinders
        wider scale IoT adoption.</p>
      <p>The primary benefit of a standardized mechanism
        for describing devices and device types is the
        capability of deploying devices to different cloud
        environments without the need of doing customization
        at device software / firmware level, i.e., installing
        cloud specific code to a device. This implies that
        the solution is flexible enough to describe devices
        in a way that allows on-boarding and using devices
        in multiple IoT cloud environments.</p>
      <p>This drives adoption of Web of Things devices,
        since it enables easy usage of new devices in an
        existing deployment, as well as migration of
        existing devices from one cloud to the other.</p>
    </section>

    <section id="virtual-thing">
      <h3>Virtual Things</h3>   
      <p>A <a>Virtual Thing</a> is a <a>Service</a> that acts as a placeholder 
        for one or more other <a>Things</a>
        which provides an interface to its <a>consumers</a>.
      </p>
      <p>
        In a simple case it is an interface abstraction, which defines a common interface
        to devices, where it is possible to replace a device model with another one without changing the consumer.
      </p>
      <p>
        In a more complex scenario, a <a>Virtual Thing</a> provides a single interface for 
        multiple devices, and provides a higher level of operations to its <a>Consumers</a>.
        Individual devices can be replaced, new operations can be provided via software upgrades.
      </p>
      <p>
        A Virtual Thing will often act as an <a>Intermediary</a>.
        Examples include <a>Shadows</a> and <a>Digital Twins</a>.
      </p>
    </section>


    <section id="sec-cross-domain-collaboration">
      <h3>Cross-domain Collaboration</h3>
      <p>
        <a href="#cross-domain"></a> show an example of a
        cross-domain collaboration. In this case, each
        system involves other systems in other domains, such
        as Smart Factory with Smart City, Smart City with
        Smart Home. This type of system is called
        "Symbiotic" ecosystem, as shown in [[IEC-FOTF]].
        There are two collaboration models: direct
        collaboration and indirect collaboration. In the
        direct collaboration model, systems exchange
        information directly with each other in a
        peer-to-peer manner. In the indirect collaboration,
        systems exchange information via some collaboration
        platform. In order to maintain and continue this
        collaboration, each system provides the metadata of
        their capabilities and interfaces and adapts itself
        to others.
      </p>
      <figure id="cross-domain">
        <img src="images/wot-use-cases/cross-domain-direct.png" srcset="images/wot-use-cases/cross-domain-direct.svg"
          class="wot-arch-diagram" alt="cross domain direct use case" />
        <img src="images/wot-use-cases/cross-domain-indirect.png"
          srcset="images/wot-use-cases/cross-domain-indirect.svg" class="wot-arch-diagram"
          alt="cross domain indirect use case" />
        <figcaption>Cross-domain collaboration</figcaption>
      </figure>
    </section>
    <section id="sec-system-integration">
      <h2>System Integration</h2>
      <p>
        The previous section described various architecture
        patterns. In these patterns, some functional entities
        such as the devices including the legacy devices,
        controllers, gateways and cloud servers are located at
        physical locations such as inside building, outside
        buildings, and data centers. <a href="#system-integration"></a>
        is an overview that shows the combinations and
        communication paths of these entities.
      </p>
      <p>
        In a transport protocol layer, each entity arbitrarily
        selects a suitable role for communications. For example,
        a device may act as a server when the device provides a service
        to indefinite number of applications. On the other hand,
        if a device has limited or intermittent network connectivity,
        they may act as a client and actively send message to an application
        when network is available. Regardless of this,
        in application layer, an application sees that a device provides abstract
        interfaces to interact and the application can interact with the device
        using their abstract interfaces.
      </p>
      <figure id="system-integration">
        <img src="images/system-integration.png" srcset="images/system-integration.svg"
          class="wot-arch-diagram" alt="system integration" />
        <figcaption>System integration</figcaption>
      </figure>
    </section>
  </section>

  <section id="sec-wot-architecture">
    <h1>Abstract WoT System Architecture</h1>
    <p>
      <em>This section is normative.</em>
    </p>
    <p>
      To address the requirements and use cases that were gathered in [[?WOT-USE-CASES-REQUIREMENTS]]
      the Web of Things (WoT) builds on top of the concept of <a>Web Things</a> &ndash; usually simply called <a>Things</a>
      &ndash; that can be used by so-called <a>Consumers</a>. <a>Consumers</a> can interact with a <a>Thing</a>
      directly, or they use <a>intermediaries</a> for indirect communication.
    </p><p>
      These concepts are applicable for the various application domains of section <a href="#sec-application-domains"></a>.
      </p><p>
      This section provides the background and normative assertions to define the overall W3C Web of Things
      architecture.
    </p><p>
      As the Web of Things addresses stakeholders from different domains, certain aspects of Web technology are
      explained in more detail, in particular the concept of hypermedia.
    </p>
    <section id="sec-architecture-overview">
      <h2>Fundamental Concepts</h2>
      <p>This section introduces the fundamental concepts of the Web of Things. 
        It introduces the <a>Thing</a> abstraction that is described with <a>Thing Descriptions</a> and <a>Thing Models</a>, 
        which then can be used by <a>Consumers</a>.</p>
      <p>
        A <a>Thing</a> is an abstraction of a physical or virtual entity (e.g., a device or a room)
	and is described by standardized metadata.  A <a>Consumer</a> is an entity that can read and interpret
	the standardized metadata for a <a>Thing</a> in order to communicate with that <a>Thing</a>.
      <p>
        The <a>WoT Thing Description</a> (TD) is a standardized, machine-readable metadata representation format
        that allows <a>Consumers</a> to discover and interpret the capabilities of a <a>Thing</a> (through semantic
        annotations)
        and to adapt to different implementations (e.g., different protocols or data structures) when interacting with a
	<a>Thing</a>,
        thereby enabling interoperability across different <a>IoT platforms</a>, i.e., different ecosystems and
        standards.
	The WoT <a>Thing Model</a> (TM) is likewise a standardized, machine-readable metadata representation
	format for describing <em>classes</em> of <a>Things</a>, such as devices of a product line with common capabilities.
      </p>
      <figure id="consumer-thing">
        <img src="images/architecture/consumer-thing.png" srcset="images/architecture/consumer-thing.svg"
          class="wot-arch-diagram" alt="consumer thing" />
        <figcaption>Consumer-Thing interaction</figcaption>
      </figure>
      <p>
        A <a>Thing</a> can also be the abstraction of a <em>virtual entity</em>.
        A virtual entity is the composition of one or more <a>Things</a> (e.g., a room consisting of several sensors and
        actuators).
        One option for the composition is to provide a single, consolidated <a>WoT Thing Description</a> that contains
        the combination of capabilities for the virtual entity.
        In cases where the composition is rather complex, its <a>TD</a> may <em>link</em> to hierarchical sub-Things
        within the composition.
        The main <a>TD</a> acts as entry point and only contain general metadata and potentially overarching
        capabilities.
        This allows grouping of certain aspects of more complex <a>Things</a>.
      </p>

      <section id="metadata">
        <h3>Metadata</h3>
	<p>
	  The WoT architecture provides metadata formats to describe both specific <em>instances</em> 
	  of <a>Things</a> and <em>classes</em> of <a>Things</a>.  The metadata format for <em>instances</em> is called
	  <a>Thing Description</a> while that for <em>classes</em> is called <a>Thing Model</a>.
	</p>
        <section id="metadata-thing-descriptions">
        <h3>Thing Descriptions</h3>
	<p>A <a>Thing</a> instance is described by standardized metadata.
        <span class="rfc2119-assertion" id="arch-td-metadata">
   	  In W3C WoT, the description metadata for a <a>Thing</a> instance
	  MUST be available as a <a>WoT Thing Description</a> (TD) [[?WOT-THING-DESCRIPTION]].</span>

        The format can be processed either through classic JSON libraries or a JSON-LD processor,
        as the underlying information model is graph-based and its serialization compatible with JSON-LD 1.1
        [[?JSON-LD11]].
        The use of a JSON-LD processor for processing a TD additionally enables semantic processing
        including transformation to RDF triples, semantic inference and accomplishing tasks given
        based on ontological terms, which would make <a>Consumers</a> behave more autonomous.
        A <a>TD</a> is instance-specific (i.e., describes an individual Thing, not types of Things)
        and is the default external, textual (Web) representation of a <a>Thing</a>.
        <span class="rfc2119-assertion" id="arch-other-thing-representations">
          There MAY be other representations of a <a>Thing</a> such as an HTML-based user interface,
          simply an image of the physical entity,
          or even non-Web representations in closed systems.</span>
        <span class="rfc2119-assertion" id="arch-td-mandatory">
          To be considered a <a>Thing</a>, however, at least one <a>TD</a> representation MUST be available.</span>
      </p>
        </section>
        <section id="metadata-thing-models">
          <h3>Thing Models</h3>
          <p>
            A <a>Thing Model</a> can be used to describe common capabilities that are
            available for a set of <a>Things</a>, for example, for a large number of devices
            in a product line. In this case the <a>Thing Model</a> defines the common capabilities of
            all devices in the product line, but omits information specific to a particular device.
          </p>
          <p>
            A <a>Thing Model</a> may also be used when complete information for an instance
            is not available or is not necessary.
            For example, some IoT ecosystems implicitly handle communication separately.
            In such a case, a fully detailed <a>Thing Description</a>, e.g. with
            communication metadata, is not necessary.
            Communication metadata may also not available
            at the beginning of a Thing lifecycle phase, since a new entity has not yet been deployed
            (e.g. the IP address is not yet known).
          </p>
          
          <p>
            A <a>Thing Model</a> is used to define the basic information model
            of a <a>Thing</a> to address such kind of scenarios.
            The <a>Thing Model</a> can be seen as a template for <a>Thing Descriptions</a>, however, that have less restriction as
            defined in sections "TD Information Model" and "Representation Format"
            of the [[?WOT-THING-DESCRIPTION]]. Typically <a>Thing Model</a> examples
            does not contain any instance-specific information such as protocol specific data like IP addresses.
            However, instead of having, e.g., concrete URLs,
            <a>Thing Model</a> allows the usage of URL templates.
          </p>
          
          <figure id="thing-model">
            <img src="images/architecture/thing_model_td.png" srcset="images/architecture/thing_model_td.svg"
              class="wot-arch-diagram" alt="Thing Model" />
            <figcaption>Thing Model and its relation to the Thing Description</figcaption>
          </figure>
          
          <p>
            The Thing Model enables:
          </p>
          <ul>
            <li> onboarding and management of multiple <a>Thing</a> models, e.g., by a cloud service. </li>
            <li> simulation of devices/<a>Things</a> that have not yet been developed.</li>
            <li> developing common applications across devices from different manufacturers that share a common <a>Thing model</a>.
            </li>
            <li> combining multiple models into a <a>Thing</a>.</li>
            <li> implementation support of a concrete <a>Thing</a>.</li>
          </ul>
          <p>
            The <a>Thing Model</a> is a logical description of the interface and possible interaction with <a>Thing</a>'s
            <a>Properties</a>, <a>Actions</a>, and <a>Events</a>, however it does not contain <a>Thing</a> instance-specific
            information, such as concrete protocol usage (e.g., IP address), or even a serial number and GPS location.
            However, Thing Models allows to include, e.g., security schemes if they apply to the entire class of instances the
            model describes. They might have URLs (e.g., like token servers) that might need to be omitted or parameterized
            (with templates) although in a lot of cases these might also be given.
          </p>     
          <p>
            A <a>Thing Model</a> can be serialized in the same JSON-based format as a Thing Description which also allows JSON-LD
            processing.
            Note that a <a>Thing Model</a> cannot be validated in the same way as <a>Thing Description</a> instances, since not
            all mandatory terms of a <a>Thing Description</a> are required for a <a>Thing Model</a>.
            missing
            mandatory terms.
          </p>      
        </section>
      </section>

      <section id="links">
        <h3>Links</h3>
      </section>
      <p>
	      Links can represent relationships between things, between things and thing models, and between thing models.       
        Linking does not only apply to hierarchical <a>Things</a>, but also to relations between Things and other resources in
        general.
        Link relation types express how Things relate, for instance, a switch controlling a light or a room monitored by
        a motion sensor.
        Other resources related to a <a>Thing</a> can be documentation manuals, catalogs for spare parts, CAD files, a graphical UI,
        or any other document on the Web.
        Overall, Web linking among Things makes the Web of Things navigable, for both humans and machines.
        This can be further facilitated by providing <a>Thing Description Directories</a> that manage a catalog of <a>Things</a>,
        usually by caching their TD representation.
	</p>
	<p>
        In summary,
        <span class="rfc2119-assertion" id="arch-td-linking"><a>WoT Thing Descriptions</a>
		and <a>WoT Thing Models</a> MAY link to other <a>Things</a>, <a>WoT Thing Models</a>,
		and other resources on the Web to form a Web of Things.</span>
      </p>
      <figure id="linked-things">
        <img src="images/architecture/linked-things.png" srcset="images/architecture/linked-things.svg"
          class="wot-arch-diagram" alt="linked things" />
        <figcaption>Linked Things</figcaption>
      </figure>
      <p>
        <span class="rfc2119-assertion" id="arch-networked">Things MUST be hosted on networked system components 
	with a software stack to realize interaction through a
		network-facing interface, the <a>WoT Interface</a> of a <a>Thing</a>.</span>
        One example of this is an HTTP server running on an embedded device with sensors and actuators interfacing the
        physical entity behind the <a>Thing</a> abstraction.
        However, W3C WoT does not mandate where <a>Things</a> are hosted; it can be on the IoT device directly, an
        <a>Edge device</a> such as a gateway, or the cloud.
      </p>
      <p>
        A typical deployment challenge is a scenario where local networks are not reachable from the Internet,
        usually because of IPv4 Network Address Translation (NAT) or firewall devices.
        To remedy this situation, W3C WoT allows for <a>Intermediaries</a> between <a>Things</a> and <a>Consumers</a>.
      </p>

      <section id="intermediaries">
        <h3>Intermediaries</h3>
      </section>
      <p>
        <a>Intermediaries</a> can act as proxies for <a>Things</a>, where the <a>Intermediary</a> has a <a>WoT Thing
          Description</a> similar to the original <a>Thing</a>,
        but which points to the <a>WoT Interface</a> provided by the <a>Intermediary</a>.
        <a>Intermediaries</a> may also augment existing <a>Things</a> with additional capabilities or compose a new
        <a>Thing</a> out of multiple available <a>Things</a>,
        thereby forming a <a>Virtual Thing</a>.
        To <a>Consumers</a>, <a>Intermediaries</a> are just another kind of <a>Thing</a>, as they possess <a>WoT Thing
          Descriptions</a> and provide a <a>WoT Interface</a>.
        They may be indistinguishable from <a>Things</a> that are directly representing physical devices
        in a layered system architecture like the Web [[?REST]].
      </p>
      <figure id="intermediary">
        <img src="images/architecture/intermediary.png" srcset="images/architecture/intermediary.svg"
          class="wot-arch-diagram" alt="intermediary" />
        <figcaption>Intermediary</figcaption>
      </figure>
      <p>
        Another remedy for restricted local networks is binding the <a>WoT Interface</a> to a protocol
        that establishes the connection from the <a>Thing</a> within the local network to a publicly reachable
        <a>Consumer</a>.
      </p>
      <p>
        The concepts of W3C WoT are applicable to all levels relevant for IoT applications: the device level, edge
        level, and cloud level.
        This fosters common interfaces and APIs across the different levels and enables various integration patterns
        such as Thing-to-Thing, Thing-to-Gateway, Thing-to-Cloud, Gateway-to-Cloud, and even cloud federation,
        i.e., interconnecting cloud computing environments of two or more service providers, for IoT applications.
        <a href="#architecture-abstract"></a> gives an overview how the WoT concepts introduced above can be applied and
        combined to address the use cases described in the <em>WoT Use Cases and Requirements</em> document [[WOT-USE-CASES-REQUIREMENTS]].
      </p>
      <figure id="architecture-abstract">
        <img src="images/architecture/overview.png" srcset="images/architecture/overview.svg" class="wot-arch-diagram"
          alt="architecture overview" />
        <figcaption>Abstract Architecture of W3C WoT</figcaption>
      </figure>
    </section>
    <section id="sec-affordances">
      <h2>Affordances</h2>
      <p>
        A central aspect in W3C WoT is the provision of machine-readable metadata (i.e., <a>WoT Thing
          Descriptions</a>).
        Ideally, such metadata is self-descriptive, so that <a>Consumers</a> are able to identify
        <em>what</em> capabilities a <a>Thing</a> provides and <em>how</em> to use the provided capabilities.
        A key to this self-descriptiveness lies in the concept of <em>affordances</em>.
      </p>
      <p>
        The term affordance originates in ecological
        psychology, but was adopted in the field of
        Human-Computer Interaction [[?HCI]] based on the
        definition by Donald Norman: "'Affordance' refers to
        the perceived and actual properties of the thing,
        primarily those fundamental properties that
        determine just how the thing could possibly be
        used." [[?NORMAN]]</p>
      <p>
        An example for this is a door with a handle.
        The door handle is an affordance, which suggests that the door can be opened.
        For humans, a door handle usually also suggests <em>how</em> the door can be opened;
        an American knob suggests twisting, a European lever handle suggests pressing down.
      </p>
      <p>
        The hypermedia principle, which is one of the
        core foundations of the REST architectural style [[?REST]],
        demands that any piece of information available on
        the Web be linked to other pieces of information so
        that the consumer of the information gets explicit
        knowledge about how to navigate the Web and control
        Web applications.
        Here, the simultaneous presentation of
        information and control (provided in
        the form of hyperlinks) is a mechanism that <em>affords</em>
        Web clients the means to drive Web applications. In this
        context, an affordance is the description of a
        hyperlink (e.g., via a link relation type and link
        target attributes) suggesting Web clients how to navigate
        and possibly how to act on the linked resource.
        Hence, links provide navigation affordances.
      </p>
      <p>
        Drawn from this hypermedia principle,
        the Web of Things defines <a>Interaction Affordances</a> as metadata of a Thing
        that shows and describes the possible choices to <a>Consumers</a>, thereby suggesting
        how <a>Consumers</a> may interact with the <a>Thing</a>.
        A general <a>Interaction Affordance</a> is navigation, which is activated by following a link,
        thereby enabling <a>Consumers</a> to browse the Web of Things.
        <a href="#sec-interaction-model"></a> defines three more types of Interaction Affordances for W3C WoT:
        <a>Properties</a>, <a>Actions</a>, and <a>Events</a>.
      </p>
      <p>
        Overall, this W3C WoT definition is aligned with HCI and interaction designers, who create physical Things,
        as well as the REST and microservice community, who is working on Web services in general.
      </p>
    </section>
    <section id="sec-web-thing">
      <h2>Web Thing</h2>
      <p>
        A <a>Web Thing</a> has four architectural aspects of interest:
        its <em>behavior</em>, its <em><a>Interaction Affordances</a></em>, its <em><a>security configuration</a></em>,
        and its <em><a>Protocol Bindings</a></em>,
        as depicted in <a href="#arch-webthing"></a>.
        The behavior aspect of a <a>Thing</a> includes both the autonomous behavior and the handlers for the
        <a>Interaction Affordances</a>.
        The <a>Interaction Affordances</a> provide a model of how <a>Consumers</a> can interact with the <a>Thing</a>
        through abstract operations,
        but without reference to a specific network protocol or data encoding.
        The <a>protocol binding</a> adds the additional detail needed to map each
        <a>Interaction Affordance</a> to concrete messages of a certain protocol.
        In general, different concrete protocols may be used to
        support different subsets of <a>Interaction Affordances</a>,
        even within a single <a>Thing</a>. The <a>security configuration</a>
        aspect of a Thing represents the mechanisms used to
        control access to the <a>Interaction Affordances</a> and the management of
        related <a>Public Security Metadata</a> and <a>Private Security Data</a>.
      </p>
      <figure id="arch-webthing">
        <img src="images/architecture/webthing.png" srcset="images/architecture/webthing.svg" class="wot-arch-diagram"
          alt="web thing" />
        <figcaption>Architectural Aspects of a Thing</figcaption>
      </figure>
    </section>

    <!-- Lifecycle -->

    <section id="lifecycle">
      <h2>Lifecycle</h2>

      <p>
        In a deployment, that applies the WoT architecture principles, different entities interact with each other and
        exchange information between them.
        Elements of a WoT deployment are <a>devices</a>, <a>intermediaries</a>, <a>consumers</a> and <em>directories</em>.
        Each element has its own (intrinsic) <a>Thing</a> lifecycle.
        These elements build a system, where the entire system has a <em>System lifecycle</em>, 
        i.e. the system has several states and transitions through some states to become operational.
        This implies that devices go through their lifecycle to become operational, and devices 
        must be known to others before they can be used. 
      </p>
      <p>
        The following sections describe the <em>System lifecycle</em> and the <em>Thing lifecycle</em>. 
        They contain sample flows to illustrate the different states and phases of Things in a deployment. 
        One of the purposes of this section is to clarify terminology and ensure that a the concepts of a 
        common lifecycle model are considered by implementers of Web Things.
      </p>
      <p>
        The actor in the left hand side of these diagrams can be understood as the device owner or manufacturer.
        The actor on the right is the end user, who uses the device in an application.
      </p>

      <section id="simple-system-lifecycle">
        <h3>Simple System Lifecycle</h3>
        <p>
          The following sequence diagram shows an example of the flow of system that consists of 
          two directly communicating devices.
      </p>
      <p>
        Before a device can be used in this scenario, it has to be bootstrapped and onboarded to the consumer.
        In the onboarding operation the consumer and the device get to know each other - this may either be
        performed by a discovery process, or via a registration operation, where the consumer is registered 
        with the device or vice-versa.
      </p>
      <p>
        After an activation step (which may consist of several operations, such as provisioning, configuration etc.)
        the <a>device</a> and <a>consumer</a> are in regular operation mode.
        When the device is no longer required in this scenario, it will be offboarded from the consumer. 
        After this operation it can be decommissioned and destroyed. 
      </p>

        <figure id="fig-simple-system-lifecycle">
          <img src="images/message-flows/lifecycle-1.svg" srcset="images/message-flows/lifecycle-1.svg"
            class="wot-arch-diagram" alt="Simple System Lifecycle" />
          <figcaption>Simple System Lifecycle</figcaption>
        </figure>
      </section>

      <section id="system-lifecycle-no-directory">
        <h3>System Lifecycle with Registration</h3>
        <p>
          The following sequence diagram shows an example of the flow of system that contains three entities: 
          a device, a consumer and a directory.
        </p>
      <p>
        This flow is very similar to the flow in the previous section, in addition it contains a <em>directory</em> entity, 
        which maintains a catalog of devices. In WoT this catalog is a set of <a>thing descriptions</a>
        After a device is bootstrapped like in the previous scenario, it is registered with the directory.
      </p>
      <p>
        The directory acts as an information broker between the actor on the left and the actor on 
        the consumer side. This decouples the device owner from the consumer, where the discovery
        acts as a middle man to enable discovery for consumers.
      </p>

        <figure id="lifecycle-2">
          <img src="images/message-flows/lifecycle-2.svg" srcset="images/message-flows/lifecycle-2.svg"
            class="wot-arch-diagram" alt="Simple System Lifecycle" />
          <figcaption>System lifecycle with registration</figcaption>
        </figure>
      </section>

      <section id="thing-lifecycle">
        <h3>Thing Lifecycle</h3>
        <p>
          Bootstrapping and provisioning of devices is an essential part of
          setting up devices in all IoT protocol suites.
        </p>
        <p>
          The main scenarios for provisioning devices with WoT are as
          follows:
        </p>
        <ul>
          <li>
            A device is already provisioned and operational in a
            given deployment. Make it work with WoT.
          </li>
          <li>
            A device is already provisioned and operational in a
            given deployment. For management purposes, <em>describe</em>
            the device lifecycle stages in a <a>Thing Description</a>.
          </li>
          <li>
            Bootstrap and provision a device directly with WoT, in
            order to become operational for WoT.
          </li>
        </ul>
        <p>
          Various provisioning schemes are being used in IoT protocol suites.
          The text in this section is based on <a
            href="https://github.com/w3c/wot-architecture/tree/master/proposals">proposals</a>
          and studies,
          <a href="https://w3c.github.io/wot-architecture/proposals/lifecycle/Device-lifecycle-comparisons.pdf">
            comparing various provisioning schemes</a>, such as OCF, OneM2M,
            Lightweight OneM2M, Thing to Thing Research Group (T2TRG),
            OPC-UA/Anima, etc.
          </p>
          <p class="note">
            The provisioning model presented in this section resembles 
            the T2TRG provisioning model.
          </p>
          <p>
            Common elements of device bootstrapping and provisioning across
            various IoT protocol suites are as follows:
          </p>
            <ul>
                <li>
                    Establish the chain of trust, e.g. secure storage, keys,
                    certificates. This may involve various solutions, such
                    as manufacturer certificates, out-of-band key provisioning,
                    connecting to a provisioning server, etc.
                </li>
                <li>
                    Establish device ownership, using a provisioning tool or
                    service. For instance, the device can be owned by a network
                    entity, or network service, or service provider, or the
                    end user.
                </li>
                <li>
                    Provision the device with the access control lists for
                    the tenants or various levels of users.
                </li>
                <li>
                    Provision the device with access to the services it uses.
                </li>
                <li>
                    Configure the device with used and the exposed services.
                </li>
                <li>
                    Provision and configure the WoT runtime in the device.
                </li>
                <li>
                    Update the configurations or provisioning data.
                </li>
                <li>
                    Decommission a user, application, service, or provisioning.
                </li>
                <li>
                    Return the device to the initial state before provisioning
                    (e.g. factory reset).
                </li>
                <li>
                    Decommission and irreversibly destroy a device.
                </li>
            </ul>
          <p>
            Taken into account these provisioning flows, in general a device
            can be in one of the following states:
          </p>
            <ul>
                <li>
                    <strong>Manufactured</strong>: the device is flashed with
                    a software image. In the case it is certified for a certain
                    protocol suite, it may be permitted or capable of doing
                    only limited operations, such as a certain bootstrapping
                     procedure.
                </li>
                <li>
                    <strong>Bootstrapped</strong>: the device has an identity
                    and ownership established, being ready for the next
                    provisioning steps, like configuration, service provisioning
                    etc.
                    This state has different names in various protocol suites,
                    for instance it is called <em>onboarded</em> in OCF,
                    <em>bootstrapped</em> in T2TRG, OPC-UA, Anima, LwM2M,
                    <em>initial provisioning</em> in OneM2M, etc.
                </li>
                <li>
                    <strong>Operational</strong>: the device is provisioned
                    and configured, working in normal mode. Some configuration
                    is possible without leaving this state. That may include
                    installing and uninstalling applications, reconfiguring
                    settings, etc.
                    Note that a device can be operational in its own native
                    protocol suite and managed by a WoT gateway, or can be
                    operational for WoT (which may be an application on the device),
                    or may be operational for Wot and directly provisioned for
                    WoT.
                </li>
                <li>
                    <strong>Maintenance</strong>: the device operational state
                    is interrupted for updating its software and/or configuration.
                </li>
                <li>
                    <strong>Destroyed</strong>: the device has been wiped out
                    of all data and software. Hardware kill features may
                    be activated. The device may be physically destroyed and
                    never used again. This state is relevant for device management purposes.
                    It does not exist in OneM2M, LwM2M, OCF, T2TRG and is
                    called <em>End-of-life</em> in OPC-UA and Anima.
                </li>
            </ul>
          <figure id="fig-device-lifecycle">
            <img src="images/architecture/device-lifecycle-1.svg"
                    srcset="images/architecture/device-lifecycle-1.svg"
                    class="wot-arch-diagram" alt="Device Lifecycle" />
            <figcaption>Device Lifecycle</figcaption>
          </figure>
          <p>
            The typical transitions between lifecycle states are the
            following:
          </p>
            <ul>
                <li>
                    <strong>Bootstrapping</strong> (or onboarding): the device
                    is provisioned with an identity, the chain of trust is
                    established, e.g. secure storage, keys, certificates.
                    This may involve various solutions, such as manufacturer
                    certificates, out-of-band key provisioning, connecting
                    to a provisioning server (a quite common scenario). When
                    provisioning directly to WoT, the device may be registered
                    with a <a>Thing Description Directory</a> in this stage. During or
                    after this process, in some protocol suites rebooting in
                    a different mode of operation might be also needed.
                </li>
                <li>
                    <strong>Provisioning, configuration, commissioning</strong>:
                    the device is provisioned with all resources needed for
                    its operation (services, applications, access control,
                    databases etc), and these resources are configured for
                    operation. Also, the device may be commissioned in a
                    given environment. These may involve communication with
                    a server, for instance a <a>Thing Description Directory</a> or
                    <a>Discovery</a> services.
                </li>
                <li>
                    <strong>Settings</strong>: the device remains in
                    <em>Operational</em> state, but may update system, service
                    or application settings. In some cases, this may include
                    installing and removing applications.
                </li>
                <li>
                    <strong>Update</strong>: the device stops normal
                    operation for undergoing updates in the
                    <em>Maintenance</em> state, similar to the ones
                    during provisioning. This may include installing new
                    software, or removing, installing or updating resources
                    and their configuration.
                    It may also include re-commissioning.
                    Returning to <em>Operational</em> state may be achieved
                    by resuming operation with updated resources, or may
                    require a restart of services, or rebooting the device.
                </li>
                <li>
                    <strong>Re-bootstrapping</strong>: the device identity,
                    owner and related resources may be changed as described
                    in the <em>Bootstrapping</em> process.
                </li>
                <li>
                    <strong>Factory Reset</strong>: the device is returned
                    to its factory default state.
                </li>
                <li>
                    <strong>Destroy</strong>: the device is erased from all
                    data, software and may be physically destroyed.
                </li>
            </ul>
      </section>
    </section>

    <!-- Interaction Model -->

    <section id="sec-interaction-model">
      <h2>Interaction Model</h2>
      <p>
        Originally, a Web resource usually represented a
        document on the World Wide Web that can simply be
        fetched by a Web client. With the introduction of Web
        services, resources became more generic interaction
        entities that can implement any kind of behavior. This
        very high level of abstraction makes it hard to provide
        a loose coupling between applications and resources due to
        the manifold interaction possibilities. As a result,
        at the time of writing, typical API descriptions consist of a static mapping
        from an application intent to a resource address,
        method, request payload structure, response payload
        structure, and expected errors.
        This imposes a tight coupling between Web client and Web service.</p>
      <p>
        The <a>Interaction Model</a> of W3C WoT introduces an
        intermediate abstraction that formalizes the mapping
        from application intent to concrete protocol operations
        and also narrows the possibilities how <a>Interaction Affordances</a>
        can be modeled.
      </p>
      <p>
        <span class="rfc2119-assertion" id="arch-affordances">In
          addition to navigation affordances (i.e., Web links),
          <a>Things</a> MAY offer three other types of <a>Interaction Affordances</a>
          defined by this specification: <a>Properties</a>, <a>Actions</a>, and <a>Events</a>.</span>
        While this narrow waist allows to decouple <a>Consumers</a> and <a>Things</a>,
        these four types of <a>Interaction Affordances</a> are still able to model virtually all interaction
        kinds found in IoT devices and services.
      </p>
      <section>
        <h3>Properties</h3>
        <p>
          A <a>Property</a> is an <a>Interaction Affordance</a> that exposes the state of the <a>Thing</a>.
          The state exposed by a <a>Property</a> can be retrievable (readable).
          Optionally, the state exposed by a Property may be updated (writable).
           <a>Things</a> may choose to make Properties observable by pushing the new state after a change
            (cf. Observing Resources [[?RFC7641]]).
         In the case of a read-only state, an Action can be used to update the state.
        </p>
        <p>
          <span class="rfc2119-assertion" id="arch-property-dataschema">
            If the data format is not fully specified by the Protocol Binding used (e.g., through a media type),
            Properties MAY contain one <a>data schema</a> for the exposed state.</span>
        </p>
        <p>
          Examples of Properties are sensor values (read-only), stateful actuators (read-write),
          configuration parameters (read-write), Thing status (read-only or read-write), or computation results
          (read-only).
        </p>
      </section>
      <section>
        <h3>Actions</h3>
        <p>
          An <a>Action</a> is an <a>Interaction Affordance</a> that allows to invoke a function of the <a>Thing</a>.
          <span class="rfc2119-assertion" id="arch-action-functions">
            An Action MAY manipulate state that is not directly exposed (cf. Properties),
            manipulate multiple Properties at a time, or manipulate Properties based on internal logic (e.g., toggle).</span>
          <span class="rfc2119-assertion" id="arch-action-process">
            Invoking an Action MAY also trigger a process on the Thing that manipulates state
            (including physical state through actuators) over time.</span>
        </p>
        <p>
          <span class="rfc2119-assertion" id="arch-action-dataschema">
            If the data format is not fully specified by the Protocol Binding used (e.g., through a media type),
            Actions MAY contain <a>data schemas</a> for input parameters and output results.</span>
        </p>
        <p>
          Some examples for Actions are setting multiple Properties simultaneously,
          changing Properties over time such as fading the brightness of a light (dimming)
          or with a process that shall not be disclosed such as a proprietary control loop algorithm,
          or invoking a long-lasting process such as printing a document.</p>
      </section>
      <section>
        <h3>Events</h3>
        <p>
          An <a>Event</a> is an <a>Interaction Affordance</a>, which describes an event source 
          that pushes data asynchronously from the <a>Thing</a> to the <a>Consumer</a>.
          Here not state, but state transitions (i.e., events) are communicated.
          <span class="rfc2119-assertion" id="arch-event-trigger">
            Events MAY be triggered through conditions that are not exposed as Properties.</span>
        </p>
        <p>
          <span class="rfc2119-assertion" id="arch-event-dataschema">
            If the data is not fully specified by the Protocol Binding used (e.g., through a media type),
            Events MAY contain <a>data schemas</a> for the event data and subscription control messages
            (e.g., a callback URI to subscribe with a Webhook).</span>
        </p>
        <p>
          Examples of <a>Events</a> are discrete events such as an alarm or samples of a time series that are sent regularly.
        </p>
      </section>
    </section>
    <section id="sec-hypermedia-controls">
      <h2>Hypermedia Controls</h2>
      <p>
        On the Web, an affordance is the simultaneous presentation of information and controls,
        such that the information becomes the affordance through which the user obtains choices.
        For humans, the information is usually text or images describing or decorating a hyperlink.
        The control is a Web link, which includes at least the URI of the target resource,
        which can be dereferenced by the Web browser (i.e., the link can be followed).
        But also machines can follow links in a meaningful way, when the Web link is further described
        by a relation type and a set of target attributes.
        A <a>hypermedia control</a> is the machine-readable description of <em>how</em> to activate an affordance.
        <a>Hypermedia controls</a> usually originate from a Web server and are discovered in-band while a Web client is
        interacting with the server.
        This way, Web servers can drive clients through Web applications dynamically,
        by taking their current state and other factors such as authorization into account.
        This is opposed to out-of-band interface descriptions that need to be preinstalled or hardcoded into clients
        (e.g., RPC, WS-* Web services, HTTP services with fixed URI-method-response definitions).
      </p>
      <p>
        W3C WoT makes use of two kinds of <a>hypermedia controls</a>:
        <em> Web links</em> [[!RFC8288]], the well-established control to navigate the Web,
        and <em>Web forms</em> as a more powerful control to enable any kind of operation.
        Links are already used in other IoT standards and <a>IoT platforms</a> such as
        CoRE Link Format [[?RFC6690]], OMA LWM2M [[?LWM2M]], and OCF [[?OCF]].
        <em>Form</em> is a new concept that besides W3C WoT is also introduced by the
        <em>Constrained RESTful Application Language (CoRAL)</em> [[?CoRAL]] defined by the IETF.
      </p>
      <section id="sec-hypermedia-links">
        <h3>Links</h3>
        <p>
          <em>Links</em> enable <a>Consumers</a> (or Web clients in the broader sense) to change the current context
          (cf. the set of resource representations currently rendered in the Web browser)
          or to include additional resources into the current context,
          depending on the relation between context and link target.
          <a>Consumers</a> do so by <em>dereferencing</em> the target URI,
          that is, fetching the resource representation by following a link.
        </p>
        <p>
          W3C WoT follows the definitions of Web Linking [[!RFC8288]],
          where a link is comprised of:
        </p>
        <ul>
          <li>a link context,</li>
          <li>a relation type,</li>
          <li>a link target, and</li>
          <li>optionally target attributes.</li>
        </ul>
        <p>
          Link relation types are either a set of predefined tokens that are registered with IANA [[?IANA-RELATIONS]], 
          (e.g. <code>stylesheet</code>),
          or extension types in the form of URIs [[!RFC3986]].
          <span class="rfc2119-assertion" id="arch-rel-types">
            Extension relation types MUST be compared as strings using ASCII case-insensitive comparison,
            (c.f. <a href="https://infra.spec.whatwg.org/#ascii-case-insensitive">ASCII case insensitive</a>).
            (If they are serialized in a different format they are to be converted to URIs).</span>
          <span class="rfc2119-assertion" id="arch-rel-type-lowercase">
            Nevertheless, all-lowercase URIs SHOULD be used for extension relation types [[!RFC8288]].</span>
        </p>
        <p>
          In the Web of Things, <em>links</em> are used for <a>Discovery</a> and to express relations between <a>Things</a>
          (e.g., hierarchical or functional)
          and relations to other documents on the Web
          (e.g., documentation manuals or alternative representations such as CAD models).
        </p>
      </section>
      <section id="sec-hypermedia-forms">
        <h3>Forms</h3>
        <p>
          Forms enable <a>Consumers</a> (or Web clients in the broader sense) to perform operations that go beyond
          dereferencing a URI
          (e.g., to manipulate the state of a Thing).
          <a>Consumers</a> do so by <em>filling out</em> and <em>submitting</em> the form to its submission target.
          This usually requires more detailed information about the contents of the (request) message than a link can
          provide
          (e.g., method, header fields, or other protocol options).
          Forms can be seen as a request template,
          where the provider pre-filled parts of the information according to its own interface and state,
          and left parts blank to be filled by the <a>Consumers</a> (or Web client in general).
        </p>
        <p>
          W3C WoT defines forms as new <a>hypermedia control</a>.
          Note that the definition in CoRAL is virtually identical, and hence compatible [[?CoRAL]].
          In CoRAL a form is comprised of:
        </p>
        <ul>
          <li>a form context,</li>
          <li>an operation type,</li>
          <li>a submission target,</li>
          <li>a request method, and</li>
          <li>optionally form fields.</li>
        </ul>
        <p>
          A form can be viewed as a statement of "To perform an
          <code>operation type</code>
          operation on
          <code>form context</code>
          , issue a
          <code>request method</code>
          request to
          <code>submission target</code>
          " where the optional form fields may further describe the required request.
        </p>
        <p>
          <span class="rfc2119-assertion" id="arch-form-iris">
            Form contexts and submission targets MUST both be
            Internationalized Resource Identifiers (IRIs)
            [[!RFC3987]].</span>
          However, in the common case, they will
          also be URIs [[!RFC3986]], because many protocols
          (such as HTTP) do not support IRIs.</p>
        <p>
          <span class="rfc2119-assertion" id="arch-form-iris2">
            Form context and submission target MAY point to
            the same resource or different resources, where the
            submission target resource implements the operation
            for the context.</span></p>
        <p>The operation type identifies the semantics of
          the operation. Operation types are denoted similar
          to link relation types.</p>
        <p>
          <span class="rfc2119-assertion" id="arch-op-request-method">
            The request method MUST identify one method of
            the standard set of the protocol identified by the
            submission target URI scheme.</span>
        </p>
        <p>
          <span class="rfc2119-assertion" id="arch-op-expected-request">
            Form fields are optional and MAY further specify the
            expected request message for the given operation.</span>
          Note that this is not limited to the payload, but may affect also protocol headers.
          <span class="rfc2119-assertion" id="arch-op-form-fields-protocol">
            Form fields MAY depend on the protocol used for the
            submission target as specified in the URI scheme.</span>
          Examples are HTTP header fields,
          CoAP options, the protocol-independent media type [[!RFC2046]] including parameters (i.e., full content type)
          for the request payload, or information about the expected response.
        </p>
        <p class="note">As of this specification, the
          well-known operation types are a fixed set that
          results from the WoT <a>Interaction Model</a>. Other
          specifications may define further well-known
          operation types that are valid for their respective
          document format or form serialization. Later versions of
          this specification or another specification may set up an IANA registry in
          the future to enable extension and a more
          generic Web form model that may be applied beyond
          WoT specifications.
        </p>
      </section>
    </section>
    <section id="sec-protocol-bindings">
      <h2>Protocol Bindings</h2>
      <p>
        A <a>Protocol Binding</a> is the mapping from an <a>Interaction Affordance</a> to concrete messages of a specific
        protocol such as HTTP [[?RFC7231]], CoAP [[?RFC7252]], or MQTT [[?MQTT]].
        It informs the <a>Consumer</a> <em>how</em> to activate the <a>Interaction Affordance</a> through a
        network-facing interface.
        The <a>Protocol Bindings</a> follow the Uniform Interface constraint of REST [[?REST]] to support
        interoperability.
        Thus, not all communication protocols are eligible to implement <a>Protocol Bindings</a> for W3C WoT;
        the requirements are given in the assertions below.
      </p>
      <p>
        In the door example given in <a href="#sec-affordances"></a>, the <a>Protocol Binding</a> corresponds to the
        door handle at the level of knob vs lever,
        which suggests <em>how</em> the door can be opened.
      </p>
      <section>
        <h3>Hypermedia-driven</h3>
        <p>
          <span class="rfc2119-assertion" id="arch-hypermedia">
            Interaction Affordances MUST include one or more Protocol Bindings.</span>
          <span class="rfc2119-assertion" id="arch-hypermedia-protocol-binding">
            <a>Protocol Bindings</a> MUST be serialized as <a href="#sec-hypermedia-controls">hypermedia controls</a> to be self-descriptive on how to
            activate the <a>Interaction Affordance</a>.</span>
          The authority of the <a>hypermedia controls</a> can be the <a>Thing</a> itself, producing the <a>TD</a> document
          at runtime (based on its current state and including network parameters such as its IP address)
          or serving it from memory with only the current network parameters inserted.
          The authority can also be an external entity that has full and up-to-date knowledge of the <a>Thing</a>
          including its network parameters and internal structure (e.g., software stack).
          This enables a loose coupling between <a>Things</a> and <a>Consumers</a>, allowing for an independent
          lifecycle and evolution.
          <span class="rfc2119-assertion" id="arch-hypermedia-caching">
            The <a>hypermedia controls</a> MAY be cached outside the <a>Thing</a>
            and used for offline processing if caching metadata is available to determine the freshness.</span>
        </p>
      </section>
      <section id="sec-arch-URIs">
        <h3>URIs</h3>
        <p>
          Hypermedia controls rely on URIs [[!RFC3986]] to identify link and submission targets.
          Thereby, the URI scheme (the first component up to ":") identifies the
          communication protocol to be used for <a>Interaction Affordance</a>s with the Thing.
          W3C WoT refers to these protocols as <a>transport protocols</a>.
        </p>
      </section>
    </section>
      <section id="media-types">
        <h3>Media Types</h3>
        <p>
          <span class="rfc2119-assertion" id="arch-media-type">All
            data (a.k.a. content) exchanged when activating Interaction Affordances
            MUST be identified by a media type [[!RFC2046]] in the Protocol Binding.</span>
          Media types are labels to identify representation formats, for instance
          <code>application/json</code>
          for JSON [[RFC8259]] or
          <code>application/cbor</code>
          for CBOR [[?RFC7049]].
          They are managed by IANA.
        </p>
        <p>
          Some media types might need additional parameters to fully specify the representation format used.
          Examples are <code>text/plain; charset=utf-8</code> or
          <code>application/ld+json; profile="http://www.w3.org/ns/json-ld#compacted"</code>.
          This needs to be considered in particular when describing data to be sent to <a>Things</a>.
          There might also be standardized transformations on the data such as content coding [[?RFC7231]].
          <span class="rfc2119-assertion" id="arch-media-type-extra">
            Protocol Bindings MAY have additional information that specifies representation formats
            in more detail than the media type alone.</span>
        </p>
        <p>
          Note that many media types only identify a generic
          serialization format that does not provide further
          semantics for its elements (e.g., XML, JSON, CBOR).
          <span class="rfc2119-assertion" id="arch-schema">Thus, 
	   the Interaction Affordance for structured data types SHOULD 
           be associated with a <em><a>data schema</a></em> to provide more detailed 
	   syntactic metadata for the data exchanged.</span>
	   Details are further described in the <a>WoT Thing Description</a> specification [[WOT-THING-DESCRIPTION]].
        </p>
    </section>
    <section id="sec-i18n">
      <h3>Internationalization</h3>
      <p>
        Web of Things support interoperable internationalization and allows 
        to use to work with multilingual data such as for User Interfaces. 
        The design and implementation of multilingual Web of Things implementations 
        is guided by the Thing Description [[?WOT-THING-DESCRIPTION]] specification. 
        It describes how human-readable text in different languages can be 
        applied based on established standards such as from [[JSON-LD]] and [[BCP47]].
      </p>
    </section>

    <section id="sec-wot-servient-architecture-high-level">
      <h2>WoT System Components and their Interconnectivity</h2>

      <p>Section <a href="#sec-architecture-overview"></a> described the
        WoT architecture in terms of the abstract WoT architecture components
        such as <a>Things</a>, <a>Consumers</a> and <a>Intermediaries</a>.
        When those components are implemented as
        a software stack to take a specific role in the WoT architecture,
        such software stacks are called <a>Servients</a>.
        Systems that are based on the WoT architecture involve <a>Servients</a>,
        which are communicating with each other to achieve the goals of a system.</p>

      <p>This section uses system configuration diagrams to illustrate
        how <a>Servients</a> work together to build systems based on the WoT architecture.</p>

      <p>A <a>Thing</a> can be implemented by a <a>Servient</a>. In a <a>Thing</a>, 
        a <a>Servient</a> software stack contains a representation of 
        a <a>Thing</a> called <a>Exposed Thing</a>, and makes its <a>WoT Interface</a> 
        available  to <a>Consumers</a> of the <a>Thing</a>.
        This <a>Exposed Thing</a> may be used by other software components on 
        the <a>Servient</a> (e.g., applications) to implement the behavior of the thing.</p>


      <figure id="servient-thing-exposedThing">
        <img src="images/architecture/servient-thing-exposedThing.png"
          srcset="images/architecture/servient-thing-exposedThing.svg" class="wot-arch-diagram"
          alt="servient as a thing" />
        <figcaption>Servient as a Thing</figcaption>
      </figure>

      <p>On the other hand, <a>Consumers</a> are always implemented by
        <a>Servients</a>, as they must be able to process the <a>Thing Description</a> (TD)
        format and must have a protocol stack that can be configured through
        <a>Protocol Binding</a> information contained in the TDs.</p>
      <p>In a <a>Consumer</a>, a <a>Servient</a> software stack provides
        a representation of a <a>Thing</a> called <a>Consumed Thing</a>,
        and makes it available to those applications running on the <a>Servient</a>
        that need to process TDs to interact with <a>Things</a>.</p>

      <figure id="servient-consumer-consumedThing">
        <img src="images/architecture/servient-consumer-consumedThing.png"
          srcset="images/architecture/servient-consumer-consumedThing.svg" class="wot-arch-diagram"
          alt="servient as a consumer" />
        <figcaption>Servient as a Consumer</figcaption>
      </figure>

      <p>A <a>Consumed Thing</a> instance in the <a>Servient</a> software stack serves
        to separate the protocol level complexity from applications.
        It is communicating with <a>Exposed Things</a> on behalf of the application.</p>

      <p>Similarly, an <a>Intermediary</a> is yet another WoT
        architecture component implemented by a <a>Servient</a>.
        An <a>Intermediary</a> is located between a <a>Thing</a> and its <a>Consumers</a>,
        performing the roles of both a <a>Consumer</a> (to the Thing)
        and a <a>Thing</a> (to the Consumers).
        In an <a>Intermediary</a>, a <a>Servient</a> software stack contains
        the representations of both a <a>Consumer</a> (<a>Consumed Thing</a>)
        and a <a>Thing</a> (<a>Exposed Thing</a>).</p>

      <figure id="servient-intermediary">
        <img src="images/architecture/servient-intermediary.png" srcset="images/architecture/servient-intermediary.svg"
          class="wot-arch-diagram" alt="servient as an intermediary" />
        <figcaption>Servient as an Intermediary</figcaption>
      </figure>

      <section>
        <h3>Direct Communication</h3>
        <p>
          <a href="#high-level-application-device"></a> shows
          direct communication between a <a>Thing</a>, which is
          exposing <a>Interaction Affordances</a> through <a>Thing Descriptions</a>,
          and a <a>Consumer</a> that uses the <a>Thing</a> by means of
          the <a>Interaction Affordances</a>.
          Direct communication applies when both <a>Servients</a>
          use the same network protocol(s) and are accessible
          to each other.
        </p>

        <figure id="high-level-application-device">
          <img src="images/architecture/servient-consumer-thing.png"
            srcset="images/architecture/servient-consumer-thing.svg" class="wot-arch-diagram"
            alt="high-level architecture of consumer and thing" />
          <figcaption>High-level architecture of
            Consumer and Thing</figcaption>
        </figure>

        <p>An <a>Exposed Thing</a> is the software representation of
          a <a>Thing</a> abstraction, serving a <a>WoT Interface</a>
          of the <a>Interaction Affordances</a> provided by the <a>Thing</a>.</p>

        <p>A <a>Consumed Thing</a> is the software representation of
          a remote <a>Thing</a> being consumed by a <a>Consumer</a>, serving as
          the interface to the remote <a>Thing</a> for the applications.
          A <a>Consumer</a> can generate a <a>Consumed Thing</a> instance
          by parsing and processing a <a>TD</a> document.
          Interactions between a <a>Consumer</a> and a <a>Thing</a>
          are performed by the <a>Consumed Thing</a> and the <a>Exposed Thing</a>
          exchanging messages over a direct network connection between them.</p>
      </section>
      <section>
        <h3>Indirect Communication</h3>

        <p>
          In <a href="#high-level-application-intermediary-device-new"></a>,
          a <a>Consumer</a> and a <a>Thing</a> connect to each other
          via an <a>Intermediary</a>. An <a>Intermediary</a> is required
          if the <a>Servients</a> use different protocols
          or if they are on different networks that require
          authentication and provide access control (e.g.
          firewalls).
        </p>

        <figure id="high-level-application-intermediary-device-new">
          <img src="images/architecture/servient-consumer-intermediary-thing.png"
            srcset="images/architecture/servient-consumer-intermediary-thing.svg" class="wot-arch-diagram"
            alt="high-level architecture with intermediary" />
          <figcaption>High-level architecture
            with Intermediary</figcaption>
        </figure>

        <p>An <a>Intermediary</a> combines <a>Exposed Thing</a> and
          <a>Consumed Thing</a> functionality. The functionality of
          <a>Intermediaries</a> includes relaying messages for the
          <a>Interaction Affordance</a>s between a <a>Consumer</a> and a <a>Thing</a>,
          optionally caching the <a>Thing</a>'s data for faster response, and
          transforming communication when the functionality of the
          <a>Thing</a> is extended by the <a>Intermediary</a>.
          In an <a>Intermediary</a>, a <a>Consumed Thing</a> creates
          a proxy object of the <a>Exposed Thing</a> of a <a>Thing</a>,
          and a <a>Consumer</a> can access the proxy object
          (i.e., the <a>Exposed Thing</a> of the <a>Intermediary</a>)
          through its own <a>Consumed Thing</a>.</p>

        <p><a>Consumer</a> and <a>Intermediary</a> can
          communicate in a different protocol than <a>Intermediary</a> and <a>Thing</a>.
          For example, an <a>Intermediary</a> can
          provide a bridge between a <a>Thing</a> that uses CoAP and
          the application of a <a>Consumer</a> that uses HTTP.
        </p>
        <p>
          Even when there are
          multiple different protocols used between <a>Intermediary</a> and <a>Things</a>,
          <a>Consumer</a> can indirectly communicate with those <a>Things</a>
          using a single protocol through the <a>Intermediary</a>. The same
          is true for the authentication. The <a>Consumed Thing</a> of a <a>Consumer</a> only
          needs to authenticate with the <a>Exposed Things</a> of the <a>Intermediary</a>
          using a single security mechanism,
          while the <a>Intermediary</a> might need multiple security mechanism
          to authenticate with different <a>Things</a>.
        </p>

        <p>Usually, an <a>Intermediary</a> generates the <a>Thing Description</a>
          for its proxy object based on the <a>Thing Description</a>
          of the originating <a>Thing</a>.
          Depending on the requirements of the use cases, the TD for the
          proxy object may either use the same identifier
          as the TD of the original <a>Thing</a>, or it gets assigned
          a new identifier.
          <span class="rfc2119-assertion" id="arch-intermediary-td-extra-protocols">
            If necessary, a TD generated by an <a>Intermediary</a> MAY contain
            interfaces for other communication protocols.</span>
        </p>
      </section>
    </section>
  </section>

  <section id="sec-building-blocks" class="informative">
    <h1>WoT Building Blocks</h1>

    <p> The Web of Things (WoT) building blocks allow the
      implementation of systems that conform with the abstract WoT
      Architecture. The specifics of these building blocks are
      defined in separate specifications; this section provides an
      overview and a summary.
    </p>
    <p> The WoT building blocks support each of the architectural
      aspects of a <a>Thing</a> discussed in <a href="#sec-web-thing"></a>
      and depicted in <a href="#arch-webthing"></a>. The individual building
      blocks are shown in the context of an abstract <a>Thing</a> in
      <a href="#arch-building-blocks"></a>. This is an abstract
      view and does not represent any particular
      implementation; instead it illustrates the
      relationship between the building blocks and the main
      architectural aspects of a <a>Thing</a>.
      In this figure the WoT building blocks
      are highlighted with black outlines.
      The <a>WoT Thing Description</a> is a key building block that 
      provides metadata describing a <a>Thing</a> and its network interface.
      Security, a cross-cutting concern,
      is separated into public and protected private components.
      The <a>WoT Scripting API</a> is optional and the
      <a>Binding Templates</a> are informative.
      The <a>WoT Discovery</a> building block defines mechanisms for 
      distributing <a>Thing Descriptions</a>; a <a>Thing</a> can provide
      <a>Thing Descriptions</a> directly, or they can be provided
      by a <a>Thing Description Directory</a> service.
    </p>
    <figure id="arch-building-blocks">
      <img src="images/bblocks/abstract2.png" srcset="images/bblocks/abstract2.svg" class="wot-arch-diagram"
        alt="wot building blocks" />
      <figcaption>Relationship of WoT Building Blocks
        to the Architectural Aspects of a Thing.</figcaption>
    </figure>
    <p> In the following sections we will provide additional
      information on each WoT building block:
      the <a href="#sec-thing-description">WoT Thing Description</a>, 
      the <a href="#sec-discovery">WoT Discovery</a> mechanisms, 
      the <a href="#sec-binding-templates">WoT Binding Templates</a>,
      and the <a href="#sec-scripting-api">WoT Scripting API</a>.
      Security, although it is a cross-cutting concern, can
      be considered an additional building block.
    </p>

    <section id="sec-thing-description">
      <h2>WoT Thing Description</h2>
      <p> The <a>WoT Thing Description</a> (TD) specification
        [[?WOT-THING-DESCRIPTION]] defines an <em>information model</em>
        based on a semantic vocabulary and a <em>serialized
          representation based on JSON</em>. <a>TDs</a> provide rich metadata
        for <a>Things</a> in a way that is both human-readable and
        machine-readable. Both the information model and
        the representation format of <a>TDs</a> are aligned with Linked
        Data [[?LINKED-DATA]], so that besides raw JSON
        processing, implementations may choose to make use of
        JSON-LD [[?JSON-LD11]] and graph databases to enable
        powerful semantic processing of the metadata.
      </p>
      <p> A <a>Thing Description</a> describes <a>Thing</a>
        instances with general metadata such as name, ID,
        descriptions, and also can provide relation metadata
        through links to related <a>Things</a> or other documents. <a>TDs</a>
        also contain <a>Interaction Affordance</a> metadata based on
        the interaction model defined in <a href="#sec-interaction-model"></a>; <a>Public Security
          Metadata</a>; and communications metadata
        defining <a>Protocol Bindings</a>. The <a>TD</a> can be seen as the <em>index.html
          for <a>Things</a></em>, as it provides the entry point to learn
        about the services and related resources provided by a <a>Thing</a>, both
        of which are described using <a>hypermedia controls</a>.
      </p>
      <p> For semantic interoperability, <a>TDs</a> may make use
        of a <a>domain-specific vocabulary</a>, for which explicit
        extension points are provided. However, development of
        any particular <a>domain-specific vocabulary</a> is currently
        out-of-scope of the W3C WoT standardization activity.
      </p>
      <p> Three examples of potentially useful external IoT
        vocabularies are SAREF [[?SAREF]], Schema Extensions for IoT
        [[?IOT-SCHEMA-ORG]], and the W3C Semantic Sensor Network
        ontology [[?VOCAB-SSN]]. Use of such external vocabularies in <a>TDs</a> is
        optional. In the future additional <a>domain-specific
        vocabularies</a> may be developed and used with <a>TDs</a>.
      </p>
      <p> Overall, the <a>WoT Thing Description</a> building block
        fosters interoperability in two ways: First, <a>TDs</a>
        enable machine-to-machine communication in the Web of
        Things. Second, <a>TDs</a> can serve as a common,
        uniform format for developers to document and retrieve
        all the details necessary to create applications that
        can access IoT devices and make use of their data.
      </p>
      <p> TDs must be known or accessible to be useful to other
       systems and devices. The <a href="#sec-discovery">WoT Discovery</a> building block,
       described in more detail below,
       defines mechanisms by which this may be accomplished for
       both self-describing devices and for situations (brownfield devices,
       constrained devices, devices with specialized protocols, sleeping
       devices, etc.) in which having
       a separate service providing the TD is more suitable.
      </p>
    </section>

    <!-- Thing Model -->


    <section id="sec-thing-model">
      <h2>Thing Model</h2>

      <p>The <a>Thing Model</a> defines a template-based model for
          <a>Thing Description</a> instances. A <a>Thing Model</a> has no
        instance specific and only partial communication- and  security-based information. This kind
        of information is supplemented by the creation of <a>Thing Description</a>
        instantiation.
      </p>

		  <p>
        A <a>Thing Model</a> mainly describes the <a>Properties</a>, <a>Actions</a>, and <a>Events</a> and
        common metadata which then are available in all instantiated <a>Thing Descriptions</a>. This paradigm
        can be compared with abstract class or interface definitions (~Thing Model) in object-oriented programming to
		    create objects (~Thing Descriptions).Such <a>Thing Models</a> are relevant for, e.g., mass production of IoT devices,
 		    onboarding scenarios as in cloud services, or to  simulate <a>Devices</a> that have not yet been developed.
      </p>

    </section>

    <section id="wot-profiles">
      <h3>Profiles</h3>
      <p class="note">
        Currently, the <a>WoT Profile</a> specification has only been published 
        as a Working Draft.
      </p>
      <p>
      The <a>WoT Profile</a> Specification [[?WOT-PROFILE]] defines Profiles 
      that enable <em>out of the box interoperability</em> among things 
      and devices. Out of the box interoperability implies
      that devices can be integrated into various application 
      scenarios without deep level adaptations. 
      Typically only minor configuration operations are necessary 
      (such as entering a network key, or IP address) to use the 
      device in a certain scenario. 
      These actions can be done by anyone without specific training.
      </p>
<!--
      <p>
        The HTTP Baseline Profile defines a mapping to
        HTTP(S).
        The HTTP Baseline Profile is complemented by two other profiles
        that provide protocol bindings for the event mechanism:
      </p>
        <ul>
          <li>HTTP SSE Profile for Server Sent Events</li>
          <li>HTTP Webhooks Profile for Webhooks</li>
        </ul>
      <p>
        These profiles can be used stand alone, or a device can implement a 
        combination of them.
        
        It is envisioned that other profiles will be defined in the future,
        that contain mappings to other protocols.
      </p>
-->
      <section>
        <h3 id="profile-description-methodology">Profiling Methodology</h3>
        <p>
          A profile is a set of constraints and rules, which
          provide additional semantic guarantees that are applied
          to the <a>WoT Thing Description</a> specification. These constraints define a
          subset of valid <a>WoT Thing Descriptions</a> by defining
          additional rules on various aspects of the <a>WoT Thing
            Description</a>.
        </p>
  
        <table class="def">
          <tr>
            <th>Constraints on</th>
            <th>Rationale</th>
            <th>Examples</th>
          </tr>
          <tr>
            <td>vocabulary of Thing Description classes</td>
            <td>guaranteed set of metadata fields</td>
            <td>Make specific vocabulary terms mandatory,
              remove others</td>
          </tr>
          <tr>
            <td>class relationships</td>
            <td>unambiguous structure</td>
            <td>limited cardinality, e.g. only one form per
              operation per interaction affordance.</td>
          </tr>
          <tr>
            <td>values of vocabulary terms</td>
            <td>simplified processing</td>
            <td>Limit the length of characters per string.
              Always use arrays, where the spec permits a
              string or an array of strings.</td>
          </tr>
          <tr>
            <td>data schemas</td>
            <td>simplified processing</td>
            <td>No arbitrary nested objects or arrays of
              arrays.</td>
          </tr>
          <tr>
            <td>security</td>
            <td>reduced implementation effort</td>
            <td>Only a restricted set of security
              mechanisms.</td>
          </tr>
          <tr>
            <td>protocol binding</td>
            <td>guaranteed protocol semantics</td>
            <td>limited protocol(s) and protocol features,
              Example: predefined mapping of http verbs (GET/PUT) to
              operation verbs, similar constraints for other protocols.</td>
          </tr>
        </table>
  
  
        <p>These constraints and rules fall into two categories:</p>
        <ul>
          <li>constraints on the data model.</li>
          <li>constraints on the protocol binding.</li>
        </ul>
  
        <p>These two categories are orthogonal to each other,
          i.e. an information model that conforms to a profile can be
          mapped to different protocols. The protocol binding for
          each protocol may contain additional (protocol-specific)
          constraints.</p>
  
        <p>A profile is not exclusive, i.e. a thing may conform
          to multiple profiles. Profiles can build on top of each
          other or overlap, extended profiles can be built on top
          of a baseline profile.</p>
  
        <figure id="WoT-Profiles">
          <img src="images/profiles/WoTProfiles.png" class="wot-profiles" alt="WoT Profiles" />
          <figcaption>Profile architecture</figcaption>
        </figure>
      </section>
    </section>

    <!-- Discovery -->

    <section id="sec-discovery">
      <h2>WoT Discovery</h2>
      <p>The <a>WoT Discovery</a> specification
        [[?WOT-DISCOVERY]] defines mechanisms for distributing and accessing
        <a>WoT Thing Descriptions</a> over the network.  
        These mechanisms are meant to 
        simplify access to <a>Things</a> and services and support their integration.
        <a>WoT Discovery</a> mechanisms are
        not limited by the bounds of local area networks and can also support remote
        discovery.
        They are also designed to act as extensions of existing search and discovery
        standards.
        </p><p>
        One of the primary design requirements of the  
        <a>WoT Discovery</a> building block 
        is to protect the security and privacy of both consumers and providers of WoT
        data and metadata.
        In particular, <a>WoT Discovery</a> mechanisms are designed not only 
        to protect and control access to <a>WoT Thing Descriptions</a>, but also
        are designed to protect queries about such data and metadata, and
        to avoid accidental distribution of direct or inferrable metadata.  
        </p><p>
        In order to accommodate existing discovery technologies while providing
        strong privacy and security, <a>WoT Discovery</a> uses a two-stage process.
        In the first stage, an "<a>introduction</a>" is made using one of several
        first-contact mechanisms.  
        In the second stage, called "<a>exploration</a>", 
        actual <a>TDs</a> are made available,
        but only after suitable authentication and authorization.
        </p>
        <p>
          Two exploration mechanisms are provided, supporting both distribution of single TDs
          and directory services for multiple TDs:
        </p>
          <ul>
            <li>An ordinary web resource provided by an HTTP server can be used to distribute a single TD.
                  This can also be used for self-description, to allow a Thing 
                  to provide its own WoT Thing Description directly.</li>
            <li>Directory services provide searchable databases of WoT Thing Descriptions. 
                Both lightweight syntactic query mechanisms and more powerful semantic query mechanisms 
                are supported by directory services.</li>
          </ul>
        <p>
          Use of these mechanisms is encouraged, but not mandatory.
        </p>
    <section id="sec-discovery-introductions">
      <h3>Introduction Mechanisms</h3>
        <p>
        <a>Introduction</a> mechanisms are not intended to 
        provide strong security or privacy guarantees, and this allows a variety
        of existing discovery mechanisms with relatively weak security to be used,
        as long as they satisfy the following requirements:
        </p>
        <ul>
        <li>
        Any <a>introduction</a> mechanism used for <a>WoT Discovery</a> must not
        provide metadata but instead should simply result in 
        one or more opaque URLs at which metadata
        may be accessed, if and only if the user can authenticate and 
        has the appropriate authorization (access rights).
        </li>
        <li>
        <a>Introduction</a> URLs must not themselves include any metadata,
        e.g. a human-readable device type or name.  
        Randomly generated URLs are recommended.
        </li>
        </ul>
    </section>
    <section id="sec-discovery-exploration">
      <h3>Exploration Mechanisms</h3>
        <p>
        After a suitable authentication and authorization process (based on existing
        mechanisms to protect web services and existing protocol security
        negotiation mechanisms), <a>WoT Discovery</a> defines a set of second stage
        "<a>exploration</a>" mechanisms that provide actual access to metadata.
        </p><p>
        The first and simplest <a>exploration</a> mechanism defines how to fetch a <a>TD</a>
        directly from the device itself. This supports ad-hoc peer-to-peer discovery.
        However, in many circumstances (including but not limited to management of 
        large collections of TDs), an alternative <a>exploration</a> mechanism,
        the <a>WoT Thing Description Directory</a> (<a>TDD</a>) service, 
        is more appropriate.
        </p><p>
        A <a>TDD</a> provides sophisticated (but protected)
        query mechanisms to explore and retrieve WoT metadata.  
        <a>TDDs</a> also provide change notification mechanisms 
        to support secure distribution of
        <a>TD</a> updates to authorized consumers.
        Any <a>WoT Discovery</a> "exploration"
        implementation must only provide metadata and <a>TDs</a>
        after appropriate best-practice authentication and authorization.
        Suitable best-practice security mechanisms for authentication and authorization for 
        different circumstances are discussed in [[?WOT-SECURITY]].  
        Suitable mechanisms for managing access controls and keys are also discussed
        in [[?SOLID]].
        </p><p> 
        <a>TDDs</a> are not just a convenience feature but are essential in several
        WoT use cases.
        Using a <a>TDD</a> is appropriate when a <a>Thing</a> has resource restrictions
        (e.g., limited memory space, limited power), 
        c.f. <a href="#device-categories">Device Categories</a>, uses a specialized protocol
        requiring translation by an intermediary (in which case the <a>TD</a> provided by 
        the <a>TDD</a> would describe the
        translated network interface supported by the intermediary), 
        or when it is necessary to use an existing device
        (often called "brownfield" devices) 
        as part of the Web of Things but the device itself cannot be easily
        modified to self-host a TD. 
        </p><p>
        <a>TDs</a> can be registered with a <a>TDD</a> by the devices themselves
        or by an external agent.
        Use of an external agent will usually be required in the case of brownfield devices.
        </p>
       </section>
        <p>
        The <a>Discovery</a> mechanisms defined in [[?WOT-DISCOVERY]] are not mandatory, but
        they are designed to meet the above requirements and their use will enhance 
        interoperability and usability.
        </p>
    </section>

    <!-- Binding Templates -->

    <section id="sec-binding-templates" >
      <h3>WoT Binding Templates</h3>


      <p> The IoT uses a variety of protocols for accessing
        devices, since no single protocol is appropriate in all
        contexts. Thus, a central challenge for the Web of
        Things is to enable interactions with the plethora of
        different <a>IoT platforms</a> (e.g., OMA
        LWM2M, OPC UA, oneM2M) and devices that do not follow any
        particular standard, but provide an eligible interface
        over a suitable network protocol. WoT is tackling this
        variety through <a>Protocol Bindings</a>, which must meet a
        number of constraints (see <a href="#sec-protocol-bindings"></a>).
      </p> 
      <p>
        The <a>Binding Templates</a> address the aspect that an application client (a <a>Consumer</a>) can use the <a>Thing
          Description</a> to
        extract the specific metadata of the protocols (e.g. about HTTP, MQTT, Modbus, etc.), payload formats (binary, JSON,
        CBOR, EXI, etc.) and their usage in an IoT platform context (e.g., ECHONET, OPC UA).
        The metadata can be passed to a network implementation interface to establish interaction with the 
        <a>Thing</a> and to serialize / deserialize
        the payload messages. In that context, <a>Binding Templates</a> include three kinds of bindings:
        Protocol bindings, Payload format bindings, and Platform bindings.
      </p>

      <p> The non-normative <a>WoT Binding Templates</a> specification
        [[?WOT-BINDING-TEMPLATES]] provides a collection of
        blueprints that give guidance on how to interact with different <a>Things</a> 
        that use different <a>transport protocols</a>, <a>content types</a> or that are 
        different <a>IoT platforms</a> or standards (e.g., OCF, oneM2M, OMA LWM2M, OPC UA) 
        which use certain combinations of <a>transport protocols</a> and 
        <a>content types</a>. When describing a particular IoT device or platform, the corresponding
        <a>Binding Template</a> can be used to look up the communication metadata that is to be provided in the
         <a>Thing Description</a> to  support that platform.
      </p>
      <figure id="fig-binding-templates">
        <img src="images/bblocks/binding-templates.png" srcset="images/bblocks/binding-templates.svg"
          class="wot-arch-diagram" alt="binding templates" />
        <figcaption>From Binding Templates to Protocol Bindings</figcaption>
      </figure>
      <p> <a href="#fig-binding-templates"></a> shows how <a>Binding
          Templates</a> are used. Based on the protocol, media type or platform binding, 
          a <a>TD</a> is created. The <a>Consumer</a> that is processing a <a>TD</a> 
          implements the required <a>Binding Template</a> that is present in the TD by including a corresponding 
          protocol stack, media type encoder/decoder or platform stack and by configuring
           the stack (or its messages) according to the information given in the <a>TD</a> such as 
	  serialization format of the messages and header options.
      </p>

      <p>
        The <a>Binding Templates</a> spans three dimensions:
      </p>
      <ul>
        <li>
          <b>Protocol</b>
          <p>
            The Web of Things uses the term <a>transport protocol</a> for the underlying, standardized
            application-layer protocol without application-specific options or <a>subprotocol</a> mechanisms.
            The URI scheme found in the form of an <a>Interaction Affordance</a> and the associated protocol endpoint URI 
            contains the information required to identify the <a>transport protocol</a>, e.g., HTTP, CoAPS, or WebSocket through 
            <code>http</code>, <code>coaps</code>, or <code>ws</code>, respectively.
          </p>
          <ul>
            <li>
                <b>Subprotocol</b>
                <p>
                  <a>Transport protocols</a> may have to use information provided by an extension mechanisms to interact successfully.
                  Such <a>subprotocols</a> cannot be identified from the URI scheme alone and must be declared explicitly
                  using the <code>subprotocol</code> field inside forms.
                  Examples for HTTP are long polling [[?RFC6202]] (<code>longpoll</code>) or 
                  Server-Sent Events [[?HTML]] (<code>sse</code>).
                </p>
            </li>
          </ul>
        </li>
        <li>
          <b>Payload Representation</b>
          <p>
            Representation formats (a.k.a. serializations) used for exchanging data can differ between protocols, 
            <a>IoT Platforms</a> and standards.
            The media type [[?RFC2046]] identifies these formats, while media type parameters may specify them further.
            Forms may contain the media type and optional parameters in additional form fields such as a content type 
            field known from HTTP, which combines media type and its potential parameters
            (e.g., <code>text/plain; charset=utf-8</code>).
          </p>
        </li>
        <li>
          <b>Platforms and Standards</b>
          <p>
            <a>IoT Platforms</a> and standards often introduce specific modifications at the application layer such as 
            platform-specific HTTP header fields or CoAP options. 
            They can also contain specific payload structures on top of the media types that need to be accurately 
            incorporated into each message between the Thing and its Consumer.
            Both the protocol modification and payload representation specific to different platforms can be represented
            in <a>TDs</a> using the best practices documented in binding templates for platforms and standards.
          </p>
        </li>
      </ul>
    </section>

    <!-- Scripting -->

    <section id="sec-scripting-api">
      <h3>WoT Scripting API</h3>
      <p> The <a>WoT Scripting API</a> is an optional "convenience"
        building block of W3C WoT that eases IoT application
        development by providing an ECMAScript-based API [[ECMAScript]] similar
        to the Web browser APIs.
        By integrating a scripting runtime system into the <a>WoT Runtime</a>,
        the <a>WoT Scripting API</a> enables using portable application scripts
        that define the behavior of <a>Things</a>, <a>Consumers</a>,
        and <a>Intermediaries</a>.
      </p>
      <p> Traditionally, IoT device logic is implemented in
        firmware, which results in productivity constraints
        similar to that of embedded development, including a
        relatively complex update process. The <a>WoT
          Scripting API</a> in contrast enables
        implementing device logic by reusable scripts executed
        in a runtime system for IoT applications. It is similar
        to that of a Web browser, and aims to improve
        productivity and reduce integration costs. Furthermore,
        standardized APIs enable portability for application
        modules, for instance, to move compute-intense logic
        from a device up to a local gateway, or to move
        time-critical logic from the cloud down to a gateway or
        edge node.
      </p>
      <p> The non-normative <a>WoT Scripting API</a> specification [[?WOT-SCRIPTING-API]] defines
        the structure and algorithms of the programming
        interface that allows scripts to discover, consume,
        and expose <a>WoT Thing Descriptions</a>. The
        runtime system of the <a>WoT Scripting API</a> instantiates local
        objects that act as an interface to other <a>Things</a> and
        their <a>Interaction Affordances</a> (<a>Properties</a>,
        <a>Actions</a>, and <a>Events</a>). It also allows scripts to expose
        <a>Things</a>, that is, to define and implement <a>Interaction
          Affordances</a> and publish a <a>Thing Description</a>.
      </p>
    </section>

    <!-- Security Guidelines -->

    <section id="sec-security-guidelines">
      <h3>WoT Security and Privacy Guidelines</h3>
      <p> Security is a cross-cutting concern and should be
        considered in all aspects of system design. In the WoT
        architecture, security is supported by certain explicit
        features, such as support for <a>Public Security Metadata</a> in <a>TDs</a>
        and by separation of concerns in the design of the
        <a>WoT Scripting API</a>. The specification for each building
        block also includes a discussion of particular security
        and privacy considerations of that building block.
        Another non-normative specification, the
        <em>WoT Security and Privacy Guidelines</em> [[?WOT-SECURITY]],
        provides additional cross-cutting security and privacy guidance.
      </p>
    </section>
  </section>

  <section id="sec-servient-implementation" class="informative">
    <h1>Abstract Servient Architecture</h1>
    <p>
      As defined in <a href="#sec-wot-servient-architecture-high-level"></a>,
      a <a>Servient</a> is a software stack that implements the WoT building blocks
      presented in the previous section.
      <a>Servients</a> can host and expose <a>Things</a> and/or consume <a>Things</a>
      (i.e., host <a>Consumers</a>).
      Depending on the <a>Protocol Binding</a>,
      <a>Servients</a> can perform in both server and client role,
      hence the portmanteau naming.
    </p>
    <p>
      The previous section describes how the WoT building blocks conceptually relate to each other
      and how they correspond to the abstract WoT Architecture (see <a href="#sec-wot-architecture"></a>).
      When implementing these concepts,
      a more detailed view is necessary that takes certain technical aspects into account.
      This section describes the detailed architecture of a <a>Servient</a> implementation.
    </p>
    <p>
      <a href="#architecture-implementation"></a> shows a <a>Servient</a> implementation that is using the (optional)
      <a>WoT Scripting API</a> building block.
      Here, the <a>WoT Runtime</a> is also a Scripting Runtime system that,
      in addition to managing the WoT-specific aspects, also interprets and executes the application scripts.
      <a>Servients</a> that support the <a>WoT Scripting API</a> usually run on powerful devices, edge nodes, or in the
      cloud (c.f. <a href="#device-categories">Device Categories</a>).
      The WoT Architecture does not limit the application-facing API of the <a>WoT Runtime</a> to JavaScript/ECMAScript.
      Also other runtime systems can be used to implement a <a>Servient</a>.
    </p>
    <p>
      Section <a href="#native-impl"></a> presents an alternative <a>Servient</a> implementation without the <a>WoT
        Scripting API</a> building block.
      The <a>WoT Runtime</a> may use any programming language for its application-facing API.
      Usually, it is the native language of the <a>Servient</a> software stack,
      for instance C/C++ for embedded <a>Servients</a> or Java for cloud-based <a>Servients</a>.
      It may also be an alternative scripting language such as Lua to combine the benefits of application scripts with
      low resource consumption.
    </p>
    <figure id="architecture-implementation">
      <img src="images/servient/wot-thing-scripting.png" srcset="images/servient/wot-thing-scripting.svg"
        class="wot-arch-diagram" alt="architecture implementation" />
      <figcaption>Implementation of a Servient using the WoT Scripting API</figcaption>
    </figure>
    <p>
      The role and functionality of each module shown
      in <a href="#architecture-implementation"></a> is explained in
      the following sections.
    </p>
    <section id="behavior-implementation">
      <h2>Behavior Implementation</h2>
      <p>
        The <em>behavior</em> defines the overall application logic of a <a>Thing</a>,
        which has several aspects:
      </p>
      <p>
        It includes <em>autonomous behavior</em> of <a>Things</a> (e.g., sampling of sensors or control loops for
        actuators),
        the <em>handlers</em> for <a>Interaction Affordances</a> (i.e., the concrete actions taken when an affordance is
        activated),
        <em><a>Consumer</a> behavior</em> (e.g., controlling a <a>Thing</a> or realizing mashups), and
        <em><a>Intermediary</a> behavior</em> (e.g., simply proxying a <a>Thing</a> or composing virtual entities).
        The behavior implementation within a <a>Servient</a> defines which <a>Things</a>, <a>Consumers</a>,
        and <a>Intermediaries</a> are hosted on this component.
      </p>
      <p>
        <a href="#architecture-implementation"></a> depicts <a>Servients</a> that are implementing the optional <a>WoT
          Scripting API</a> building block,
        where portable application scripts written in JavaScript [[ECMAScript]] define the behavior.
        They are executed by a scripting runtime system that is part of the <a>WoT Runtime</a>
        (when providing the <a>WoT Scripting API</a> or any other script-based API).
        They are portable, as they are written against the common <a>WoT Scripting API</a> definitions,
        and hence can be executed by any <a>Servient</a> featuring this building block.
        This makes it possible to shift application logic between system components,
        for instance moving a <a>Consumer</a> from the cloud to an edge node to meet networking requirements,
        or to move an <a>Intermediary</a> to the cloud to fulfill growing resource demands.
        Portable applications enable to 'install' additional behavior after the deployment of a Servient.
      </p>
      <p>
        In principle, any programming language and API can be used in order to define the behavior of a Thing,
        as long as the <a>Interaction Affordances</a> are presented externally through a <a>WoT Interface</a>.
        The adaption between application-facing API and the protocol stack is handled by the <a>WoT Runtime</a>.
        See <a href="#native-impl"></a> for behavior implementation without the <a>WoT Scripting API</a> building block.
      </p>
    </section>
    <section id="wot-runtime">
      <h2>WoT Runtime</h2>
      <p>
        Technically, the <a>Thing</a> abstraction and its <a>Interaction Model</a> is implemented in a runtime system.
        This <a>WoT Runtime</a> maintains the execution environment for the behavior implementation and is able to
        expose and/or consume <a>Things</a>,
        and hence must be able to fetch, process, serialize, and serve <a>WoT Thing Descriptions</a>.
      </p>
      <p>
        Every <a>WoT Runtime</a> has an application-facing interface (i.e., an API) for the behavior implementation.
        The optional <a>WoT Scripting API</a> building block shown in <a href="#architecture-implementation"></a>
        defines such an application-facing interface that follows the <a>Thing</a> abstraction
        and enables the deployment of behavior implementations during runtime through application scripts.
        See <a href="#native-impl"></a> for alternative APIs, which can also only be available during compile time.
        In general, application logic should be executed in sandboxed execution environments
        that prevent unauthorized access to the management aspects of the <a>WoT Runtime</a> from the application code,
        in particular the <a>Private Security Data</a>.
        In multi-tenant <a>Servients</a>, different tenants should also be prevented from accessing each other's data
        without authorization.
      </p>
      <p>
        A <a>WoT Runtime</a> needs to provide certain operations to manage the lifecycle of <a>Things</a>,
        or more precisely their software abstractions and descriptions.
        A lifecycle management (LCM) system may encapsulate those lifecycle operations within a <a>Servient</a>
        and use internal interfaces to realize the lifecycle management.
        The details of such operations vary among different implementations.
        The <a>WoT Scripting API</a> includes LCM functionality, and hence represents one possible
        implementation of such a system.
      </p>
      <p>
        The <a>WoT Runtime</a> must interface with the protocol stack implementation of the <a>Servient</a>,
        as it decouples the behavior implementation from the details of the <a>Protocol Bindings</a>.
        The <a>WoT Runtime</a> usually also interfaces with the underlying system,
        for instance, to access local hardware such as attached sensors and actuators or to access system services such
        as storage.
        Both interfaces are implementation-specific,
        yet the <a>WoT Runtime</a> must provide the necessary adaption to the  <a>Thing</a> abstraction it implements.
      </p>
    </section>
    <section id="wot-scripting-api">
      <h3>WoT Scripting API</h3>
      <p>
        The <a>WoT Scripting API</a> building block defines an ECMAScript API that closely follows the <a>WoT Thing
          Description</a> specification [[?WOT-THING-DESCRIPTION]].
        It defines the interface between behavior implementations and a scripting-based <a>WoT Runtime</a>.
        Other, simpler APIs may be implemented on top of it,
        similar to, for instance, jQuery for the Web browser APIs.
      </p>
      <p>
        See [[?WOT-SCRIPTING-API]] for more details.
      </p>
    </section>
    <section id="expose-consumed-thing">
      <h2>Exposed Thing and Consumed Thing Abstractions</h2>
      <p>
        The <a>WoT Runtime</a> instantiates software representations of <a>Things</a> based on their <a>TDs</a>.
        These software representations provide the interface towards the behavior implementation.
      </p>
      <p>
        The <a>Exposed Thing</a> abstraction represents a <a>Thing</a> hosted locally
        and accessible from the outside through the protocol stack implementation of the <a>Servient</a>.
        The behavior implementation can fully control <a>Exposed Things</a> by defining their metadata and
        <a>Interaction Affordances</a>,
        and providing their autonomous behavior.
      </p>
      <p>
        The <a>Consumed Thing</a> abstraction represents a remotely hosted <a>Thing</a> for <a>Consumers</a> that needs
        to be accessed using a communication protocol.
        <a>Consumed Things</a> are proxy objects or stubs.
        The behavior implementation is restricted to reading their metadata and activating their <a>Interaction
          Affordances</a> as described in the corresponding <a>TD</a>.
        <a>Consumed Things</a> can also represent system features such as local hardware or devices behind proprietary
        or legacy communication protocols.
        In this case, the <a>WoT Runtime</a> must provide the necessary adaptation between system API and <a>Consumed
          Thing</a>.
        Furthermore, it must provide corresponding <a>TDs</a> and make them available to the behavior implementation,
        for instance, by extending whatever discovery mechanism is provided by the <a>WoT Runtime</a> through the
        application-facing API
        (e.g., the <code>discover()</code> method defined in the <a>WoT Scripting API</a> [[?WOT-SCRIPTING-API]]).
      </p>
      <p>
        When using the <a>WoT Scripting API</a>, <a>Exposed Thing</a> and <a>Consumed Thing</a>
        are JavaScript objects,
        which can be created, operated on, and destroyed by application scripts.
        However, access may be restricted through a security mechanism,
        for instance, in multi-tenant <a>Servients</a>.
      </p>
    </section>
    <section>
      <h2>Private Security Data</h2>
      <p>
        Private security data, such as a secret key for interacting with the Thing,
        is also conceptually
        managed by the <a>WoT Runtime</a>,
        but is intentionally not made
        directly accessible to the application. In fact, in the
        most secure hardware implementations, such <a>Private
          Security Data</a> is stored in a separate, isolated memory
        (e.g., on a secure processing element or TPM)
        and only an abstract set of operations (possibly even
        implemented by an isolated processor and software stack)
        is provided that limit the attack surface and prevent
        external disclosure of this data. <a>Private Security Data</a>
        is used transparently by the <a>Protocol Binding</a> to
        authorize and protect the integrity and confidentiality
        of interactions.
      </p>
    </section>
    <section>
      <h2>Protocol Stack Implementation</h2>
      <p>
        The protocol stack of a <a>Servient</a> implements the <a>WoT Interface</a> of the <a>Exposed Things</a>
        and is used by <a>Consumers</a> to access the <a>WoT Interface</a> of remote
        <a>Things</a> (via <a>Consumed Things</a>).
        It produces the concrete protocol messages to interact over the network.
        <a>Servients</a> may implement multiple protocols, and hence support multiple
        <a>Protocol Bindings</a> to enable interaction with different <a>IoT Platforms</a>.
      </p>
      <p> In many cases, where standard protocols are used,
        generic protocol stacks can be used to produce the
        platform-specific messages (e.g., one for HTTP(S)
        dialects, one for CoAP(S) dialects, and one for MQTT
        solutions, etc.). In this case, the communication
        metadata from the <a>Thing Description</a> is used to
        select and configure the right stack (e.g., HTTP with
        the right header fields or CoAP with the right options).
        Parsers and serializers for the expected payload representation
        format (JSON, CBOR, XML, etc.)
        as identified by the media type [[RFC2046]] can also be
        shared across these generic protocol stacks.
      </p>
      <p>
        See [[?WOT-BINDING-TEMPLATES]] for details.
      </p>
    </section>
    <section>
      <h2>System API</h2>
      <p>
        An implementation of a <a>WoT Runtime</a>
        may provide local hardware or system services to
        behavior implementations through the <a>Thing</a>
        abstraction, as if they were accessible over a communication
        protocol. In this case, the <a>WoT Runtime</a> should
        enable the behavior implementation to instantiate <a>Consumed Things</a>
        that internally interface with the system instead of the protocol stack.
        This can be done by listing such system Things,
        which are only available in the local <a>WoT Runtime</a>,
        in the results of the discovery mechanism provided by the
        application-facing <a>WoT Runtime</a> API.
      </p>
      <p>
        A device may also be physically external to a <a>Servient</a>,
        but connected via a proprietary protocol or a protocol
        not eligible as <a>WoT Interface</a> (see <a href="#sec-protocol-bindings"></a>).
        In this case, the <a>WoT Runtime</a> may
        access legacy devices with such protocols (e.g., ECHONET
        Lite, BACnet, X10, I2C, SPI, etc.) through proprietary APIs,
        but may again choose to expose them to the behavior implementation via
        a <a>Thing</a> abstraction. A <a>Servient</a> can then act
        as gateway to the legacy devices. This should only be
        done if the legacy device cannot be described directly
        using a <a>WoT Thing Description</a>.
      </p>
      <p>
        The behavior implementation may also access local
        hardware or system services (e.g., storage) through a
        proprietary API or other means. This is, however, out of
        scope of the W3C WoT standardization, as it hinders portability.
      </p>
    </section>
    <section id="alt-servient-impl">
      <h3>Alternative Servient and WoT Implementations</h3>
      <p>
        The <a>WoT Scripting API</a> building block is optional.
        Alternative <a>Servient</a> implementations are possible,
        where the <a>WoT Runtime</a> offers an alternative API for the application logic,
        which may be written in any programming language.
      </p>
      <p>
        Furthermore, devices or services unaware of W3C WoT can still be consumed,
        when it is possible to provide a well-formed <a>WoT Thing Description</a> for them.
        In this case, the <a>TD</a> describes a <a>WoT Interface</a> of a <a>Thing</a> that has a black-box
        implementation.
      </p>
      <section id="native-impl">
        <h3>Native WoT API</h3>
        <p>
          There are various reasons why a developer may choose
          to implement a <a>Servient</a> without using the <a>WoT
            Scripting API</a>. This may be due to insufficient
          memory or computing resources, so the developer cannot use
          the required software stack or a fully-featured scripting
          engine. Alternatively, to support their use case (for
          example, a proprietary communications protocol)
          the developer may have to use
          specific functions or libraries only available
          through a particular programming environment or
          language.
        </p>
        <p>
          In this case, a <a>WoT Runtime</a> can still be
          used, but with an equivalent abstraction and functionality
          exposed using an alternative application-facing interface instead of
          the <a>WoT Scripting API</a>.
          Except for the latter, all block descriptions in <a href="#sec-servient-implementation"></a>
          are also valid for <a href="#architecture-implementation-native"></a>.
        </p>
        <figure id="architecture-implementation-native">
          <img src="images/servient/wot-thing-native.png" srcset="images/servient/wot-thing-native.svg"
            class="wot-arch-diagram" alt="implementation native" />
          <figcaption>Implementation of a Servient Using a Native WoT API</figcaption>
        </figure>
      </section>
      <section id="existing-impl">
        <h3>Thing Description for Existing Devices</h3>
        <p>
          It is also possible to integrate <em>existing</em> IoT devices
          or services into the W3C Web of Things and to use them as <a>Things</a>
          by creating a <a>Thing Description</a> for these devices or services.
          Such a TD can either be created manually or via a tool or service.
          For example, a TD could be generated by a service that provides
          automatic translation of metadata provided by another,
          ecosystem-dependent machine-readable format.
          This can only be done, however, if the target device
          is using protocols that can be described using a <a>Protocol Binding</a>.
          The requirements for this are given in <a href="#sec-protocol-bindings"></a>.
          Much of the previous discussion also implies that a <a>Thing</a>
          provides its own <a>Thing Description</a>. While this
          is a useful pattern it is not mandatory.
          In particular, it may not be possible to modify
          existing devices to provide their
          own <a>Thing Description</a> directly. In this case the
          <a>Thing Description</a> will have to be provided
          separately using a service such as a directory
          or some other external and separate distribution mechanism.
        </p>
        <figure id="architecture-implementation-existing">
          <img src="images/servient/wot-thing-existing.png" srcset="images/servient/wot-thing-existing.svg"
            class="wot-arch-diagram" alt="implementation existing" />
          <figcaption>Integration of Existing IoT Devices into W3C WoT</figcaption>
        </figure>
      </section>
    </section>
  </section>

  <section id="sec-deployment-scenario" class="informative">
    <h1>Example WoT Deployments</h1>

    <p> This section provides various examples of how the Web of Things (WoT)
      abstract architecture may be instantiated
      when devices and services that implement the <a>Thing</a> and <a>Consumer</a> roles are
      connected in various concrete topologies and deployment scenarios.
      These topologies and scenarios are not normative, but are enabled and supported
      by the WoT abstract architecture.
    </p>
    <p>
      Before discussing specific topologies, we will
      first review the roles that <a>Things</a> and <a>Consumers</a> can
      play in a WoT network and the relationships they have with the
      <a>Exposed Thing</a> and <a>Consumed Thing</a> software abstractions.
      <a>Exposed Thing</a> and <a>Consumed Thing</a> are internally available
      to the behavior implementations of <a>Servients</a>
      in the roles of <a>Things</a> and <a>Consumers</a>, respectively.
    </p>

    <section id="sec-client-server-roles">
      <h2>Thing and Consumer Roles</h2>
      <p> A <a>Servient</a> in the role of a <a>Thing</a> creates an
        <a>Exposed Thing</a> based on a <a>Thing Description</a> (TD).
        TDs are published and made available to other <a>Servients</a>
        that are in the roles of <a>Consumers</a> or <a>Intermediaries</a>.
        TDs may be published in various different ways: the TD
        might be registered with a management system such as
        a <a>Thing Description Directory</a> service, or a <a>Thing</a>
        may provide the requesters with a TD upon receiving a request for a TD.
        It is even possible to statically associate a TD with <a>Thing</a>
        in certain application scenarios.
      </p>
      <p> A <a>Servient</a> in the role of a <a>Consumer</a> obtains the TD of a <a>Thing</a>
        using a discovery mechanism and creates a <a>Consumed Thing</a> based on the obtained TD.
        The concrete discovery mechanism depends on the individual deployment scenario:
        It could be provided by a management system such as a <a>Thing Description Directory</a>,
        a discovery protocol, through static assignment, etc.  As discussed
        elsewhere, use of the <a>Discovery</a> mechanisms defined in
        [[?WOT-DISCOVERY]] is recommended whenever possible.
      </p>
      <p>However, it should be noted that TDs describing
        devices associated with an identifiable person may potentially
        be used to infer privacy-sensitive information.
        Constraints on the distribution of such TDs must therefore be
        incorporated into any concrete TD discovery mechanism. If possible,
        steps to limit the information exposed in a TD may also have to
        be taken, such as filtering out IDs or human-readable information
        if this is not strictly necessary for a particular use case.
        Privacy issues are discussed
        at a high level in <a href="#sec-privacy-considerations"></a>
        and a more detailed discussion is given in the
        [[?WOT-THING-DESCRIPTION]]
        specification and are addressed in the [[?WOT-DISCOVERY]] specification.
      </p>
      <p>Internal system functions of a device, such as interacting with attached sensors and actuators,
        can also optionally be represented as <a>Consumed Thing</a> abstractions.
      </p>
      <p>The functions supported by the <a>Consumed Thing</a> are provided
        to the <a>Consumer</a>'s behavior implementation through a programming language
        interface. In the <a>WoT Scripting API</a>, <a>Consumed Things</a>
        are represented by objects.
        The behavior implementation (that is, the application logic) running in
        a <a>Thing</a> can engage through <a>Interaction Affordances</a> with
        <a>Consumers</a> by using
        the programming language interface provided by the <a>Exposed Thing</a>.
      </p>
      <p> A <a>Thing</a> does not necessarily represent a physical device.
        <a>Things</a> can also represent a collection of devices, or virtual services
        running in a gateway or in the cloud.
        Likewise, a <a>Consumer</a> may represent an application or service running on a gateway or cloud.
        <a>Consumers</a> can also be implemented on edge devices.
        In <a>Intermediaries</a>, a single <a>Servient</a>
        performs both the roles of a <a>Thing</a> and a <a>Consumer</a> simultaneously which are
        sharing a single <a>WoT Runtime</a>.
      </p>
    </section>
    <section id="sec-topologies-deployment-scenarios">
      <h2>Topology of WoT Systems and Deployment Scenarios</h2>
      <p>Various topologies and deployment scenarios of WoT systems are discussed in this section.
        These are only example patterns and other interconnection topologies are also possible.
        The topologies described here are derived from the Web of Things Use Cases and Requirements [[WOT-USE-CASES-REQUIREMENTS]].
      </p>
      <section id="sec-deployment-app-dev">
        <h2>Consumer and Thing on the Same Network</h2>
        <p> In the simplest interconnection topology, illustrated by <a href="#simple-conf-application-device"></a>,
          the <a>Consumer</a> and <a>Thing</a> are on the same network and can communicate
          directly with each other without any intermediaries.
          One use case where this topology arises is when the <a>Consumer</a> is an orchestration
          service or some other IoT application running on a gateway and the <a>Thing</a> is a device interfacing to
          a sensor or an actuator. However, the client/server relationship could be easily reversed;
          the client could be a device in the <a>Consumer</a> role accessing
          a service running as a <a>Thing</a> on a gateway or in the cloud.
        </p>
        <figure id="simple-conf-application-device">
          <img src="images/deployments/arch-simple-conf-consumer-thing.png"
            srcset="images/deployments/arch-simple-conf-consumer-thing.svg" class="wot-arch-diagram"
            alt="consumer and thing on the same network" />
          <figcaption>Consumer and Thing on the Same Network</figcaption>
        </figure>
        <p> If the <a>Thing</a> is in the cloud and the <a>Consumer</a> is on a local network
          (see <a href="#smart-home"></a> for an example in a Smart Home use case)
          the actual network topology may be more complex,
          for example requiring NAT traversal and disallowing certain forms of discovery.
          In such cases one of the more complex
          topologies discussed later may be more appropriate.
        </p>
      </section>
      <section id="sec-deployment-intermediaries">
        <h2>Consumer and Thing Connected via Intermediaries</h2>
        <p> An <a>Intermediary</a> plays both <a>Thing</a> and
          <a>Consumer</a> roles on the network and supports
          both the <a>Exposed Thing</a> and <a>Consumed Thing</a>
          software abstractions within its <a>WoT Runtime</a>.
          <a>Intermediaries</a> can be used for proxying between devices and
          networks or for <a>Digital Twins</a>.
        </p>
        <section id="sec-deployment-app-proxy-dev">
          <h2>Intermediary Acting as a Proxy</h2>
          <p> One simple application of an <a>Intermediary</a> is a proxy for a <a>Thing</a>.
            When the <a>Intermediary</a> acts as a proxy,
            it has interfaces with two separate
            networks or protocols. This may involve
            the implementation of additional security mechanisms
            such as providing TLS endpoints. Generally proxies
            do not modify the set of interactions, so the TD exposed
            by the <a>Intermediary</a> will have the same interactions
            as the consumed TD, however the connection metadata is modified.
          </p>
          <p> To implement this proxy pattern, the <a>Intermediary</a> obtains a TD
            of a <a>Thing</a> and creates a <a>Consumed Thing</a>.
            It creates a proxy object of the <a>Thing</a> as a software
            implementation that has the same <a>Interaction Affordances</a>.
            It then creates a TD for the proxy object with a new identifier
            and possibly with new communications metadata (<a>Protocol Bindings</a>)
            and/or new <a>Public Security Metadata</a>.
            Finally, an <a>Exposed Thing</a> is
            created based on this TD, and the <a>Intermediary</a> notifies other
            <a>Consumers</a> or <a>Intermediaries</a> of the TD via
            an appropriate publication mechanism.
          </p>
          <figure id="simple-conf-application-intermediary-device">
            <img src="images/deployments/arch-simple-conf-consumer-intermediary-thing.png"
              srcset="images/deployments/arch-simple-conf-consumer-intermediary-thing.svg" class="wot-arch-diagram"
              alt="consumer and thing connected via an intermediary acting as a proxy" />
            <figcaption>Consumer and Thing Connect via an Intermediary Acting as a Proxy</figcaption>
          </figure>
        </section>
        <section id="sec-deployment-digital-twin">
          <h2>Intermediary Acting as a Digital Twin</h2>
          <p> More complex <a>Intermediaries</a> may be known as <a>Digital Twins</a>.
            A <a>Digital Twin</a> may or may not modify the protocols or
            translate between networks, but they provide additional
            services, such as state caching, deferred updates,
            or even predictive simulation of the behavior of the target device.
            For example, if an IoT device has limited power, it
            may choose to wake up relatively infrequently, synchronize
            with a <a>Digital Twin</a>, and then immediately go to sleep again.
            In this case, typically the <a>Digital Twins</a> runs on a less power-constrained
            device (such as in the cloud or on a gateway), (c.f. <a href="#device-categories">Device Categories</a>)
            and is able to respond to interactions on the
            constrained device's behalf.
            Requests for the current state of properties
            may also be satisfied by the <a>Digital Twins</a> using cached state.
            Requests that arrive when the target IoT device is sleeping
            may be queued and sent to it when it wakes up.
            To implement this pattern, the <a>Intermediary</a>,
            i.e., the <a>Digital Twin</a> needs to know when the device is awake.
            The device implementation as a <a>Thing</a> may need to include a notification mechanism for that.
            This could be implemented using a separate <a>Consumer</a>/<a>Thing</a> pair,
            or by using <a>Event</a> interactions for this purpose.
          </p>
        </section>
      </section>
      <section id="sec-deployment-cloud">
        <h2>Devices in a Local Network Controlled from a Cloud Service</h2>
        <p> In Smart Home use cases, devices (sensors and home appliances)
          connected to a home network are often
          monitored and, in some cases, also controlled by cloud
          services. There is usually a NAT device between the home
          network to which the devices are connected and the cloud.
          The NAT device translates IP addresses as well as often providing
          firewall services, which block connections selectively.
          The local devices and cloud services can only communicate
          with each other if the communication can successfully
          traverse the gateway.
        </p>
        <p> A typical structure,
          adopted in ITU-T Recommendation Y.4409/Y.2070 [[?Y.4409-Y.2070]] ,
          is shown in <a href="#deployment-cloud-device"></a>.
          In this structure there is both a local and a remote <a>Intermediary</a>.
          The local <a>Intermediary</a> aggregates the <a>Interaction Affordances</a> from multiple
          <a>Thing</a> into a (set of) <a>Exposed Things</a>,
          which can all be mapped onto a common protocol
          (for example, HTTP, with all interactions mapped to a single
          URL namespace with a common base server and using a single port).
          This provides the remote <a>Intermediary</a> with a simple way to
          access all the <a>Things</a> behind the NAT device,
          assuming the local <a>Intermediary</a>
          has used a converged protocol that can traverse the NAT device
          and has some way to expose this service to the Internet (STUN, TURN, dynamic DNS, etc.).
          In addition, the local <a>Intermediary</a> can function as a Thing proxy, so
          even when the connected <a>Things</a> each use a different
          protocol (HTTP, MQTT, CoAP, etc.) and/or a different set of
          ecosystem conventions, the
          <a>Exposed Thing</a> can converge them into a single protocol so
          that <a>Consumers</a> do not need to be aware of the various
          protocols the <a>Things</a> use.
        </p>

        <p> In <a href="#deployment-cloud-device"></a>, there are two
          clients connected to the remote <a>Intermediary</a>, which
          has aggregated the services that reside behind the NAT border and may
          provide additional protocol translation or security services.
          In particular, the local <a>Intermediary</a> may be on a network
          with limited capacity and making that service directly available to all
          users may not be feasible. In this case access to the local
          <a>Intermediary</a> is <em>only</em> provided to the remote <a>Intermediary</a>.
          The remote <a>Intermediary</a> then implements a more general access
          control mechanism and may also perform caching or throttling to
          protect the consumer from excess traffic.
          Those consumers also will use a
          single protocol suitable for the open Internet (e.g., HTTPS) to communicate with the
          <a>Intermediary</a>, which makes the development of clients much
          simpler.
        </p>
        <p> In this topology there is NAT and firewall functionality between the consumers and things,
          but the local and remote <a>Intermediaries</a> work together to tunnel all communications
          through the firewall, so the consumers and things need to know
          nothing about the firewall.
          The paired <a>Intermediaries</a> also protect the home devices by providing
          access control and traffic management.
        </p>
        <figure id="deployment-cloud-device">
          <img src="images/deployments/arch-deploy-cloud-thing.png"
            srcset="images/deployments/arch-deploy-cloud-thing.svg" class="wot-arch-diagram" alt="cloud applications" />
          <figcaption>Cloud Applications Implemented as Consumers Connected to
            Local Devices implemented as Things via Paired Intermediaries</figcaption>
        </figure>
        <p> In more difficult cases the NAT and firewall traversal may not work exactly as
          shown. In particular, an ISP may not support publicly accessible addresses,
          or STUN/TURN and/or dynamic DNS may not be supported or available.
          In this case the <a>Intermediaries</a>
          may alternative reverse the client/server roles between them to set up an initial
          connection (with the local <a>Intermediary</a> first connecting to the remote <a>Intermediary</a>
          in the cloud), then the pair of <a>Intermediaries</a>
          may establish a tunnel (using for example, a Secure WebSocket, which uses TLS
          to protect the connection).
          The tunnel can then be used to encode all communications between the
          <a>Intermediaries</a> using a custom protocol.
          In this case the initial connection can still be made over HTTPS using standard
          ports, and from the local <a>Intermediary</a> to the remote <a>Intermediary</a> identically
          to a normal browser/web server interaction.
          This should be able to traverse most home firewalls, and since the connection
          is outgoing, network address translation will not cause any problems.
          However, even though a custom tunneling protocol is needed, the
          remote <a>Intermediary</a> can still translate this custom protocol back into
          standard external protocols. The connected <a>Consumers</a> and <a>Things</a>
          do not need to know about it.
          It is also possible to extend this example to use cases where both <a>Things</a>
          and <a>Consumers</a> can connect on either side of the NAT boundary.
          This however also requires a bidirectional tunnel to be established between
          the two <a>Intermediaries</a>.
        </p>
      </section>
      <section id="sec-deployment-discovery-with-directory">
        <h2>Discovery Using a Thing Description Directory</h2>
        <!-- "application" and "device" are used intentionally here instead of client or server, since they
     might be either! -->
        <p> Once local devices (and possibly services)
          can be monitored or controlled by services
          on cloud, a variety of additional services can be built on top.
          For example, a cloud application could change a device's
          operating condition based on an analysis of collected data.
        </p>
        <p> However when the remote <a>Intermediary</a> is a part of a cloud platform
          servicing client applications, the clients need to be able to find
          device information by, for example, accessing a
          directory of connected devices. For simplicity in the figure below
          we have assumed all local devices are implemented as <a>Things</a> and
          all cloud applications as <a>Consumers</a>.
          To make the metadata of local devices implemented as <a>Things</a>
          available to the cloud applications,
          their metadata
          can be registered with a <a>Thing Description Directory</a> service.
          This metadata is specifically the TDs of the local devices modified to
          reflect the <a>Public Security Metadata</a> and communication metadata
          (<a>Protocol Bindings</a>)
          provided by the remote <a>Intermediary</a>.
          A client application then can obtain the metadata
          it needs to communicate with local devices to
          achieve its functionality by querying the <a>Thing Description Directory</a>.
        </p>
        <figure id="deployment-cloud-directory">
          <img src="images/deployments/arch-deploy-service-directory.png"
            srcset="images/deployments/arch-deploy-service-directory.svg" class="wot-arch-diagram"
            alt="cloud directory" />
          <figcaption>Cloud Service with Thing Description Directory</figcaption>
        </figure>
        <p> In more complex situations, not shown in the figure, there
          may also be cloud services that act as <a>Things</a>.
          These can also register themselves with a <a>Thing Description Directory</a>.
          Since a <a>Thing Description Directory</a> is a Web service, it should be visible
          to the local devices through the NAT or firewall device
          and its interface can even be provided with its own TD.
          Local devices acting as <a>Consumers</a> can then
          discover the <a>Things</a> in the cloud via a <a>Thing Description Directory</a>
          and connect to the <a>Things</a> directly or via the local
          <a>Intermediary</a> if, for instance, protocol translation is needed.
        </p>
      </section>
      <section id="sec-deployment-service-to-service">
        <h2>Service-to-Service Connections Across Multiple Domains</h2>
        <p> Multiple cloud eco-systems each based on different
          IoT platforms can work together to make a larger,
          system-of-systems eco-system. Building on the previously
          discussed structure of a cloud application eco-system,
          the figure below shows two eco-systems connected to each
          other to make a system-of-systems. Consider the case in
          which a client in one eco-system (i.e., <a>Consumer</a> A
          below) needs to use a server in another eco-system
          (i.e., <a>Thing</a> B below).
          There is more than one mechanism to
          achieve this cross eco-systems application-device
          integration.
          Below, two mechanisms are
          explained, each using a figure, to show how this can be achieved.</p>
        <section id="sec-deployment-service-to-service-synchronized">
          <h3>Connection Through Thing Description Directory Synchronization</h3>
          <p> In <a href="#deployment-service-sync-directory"></a>,
            two instances of a <a>Thing Description Directory</a>
            synchronize information, which makes it possible
            for <a>Consumer</a> A to obtain the information of
            <a>Thing</a> B through <a>Thing Description Directory</a> A. As described in
            previous sections, remote <a>Intermediary</a> B maintains a shadow
            implementation of <a>Thing</a> B.
            By obtaining the TD of this shadow
            device, <a>Consumer</a> A is able to use <a>Thing</a> B through the
            remote <a>Intermediary</a> B.
          </p>
          <figure id="deployment-service-sync-directory">
            <img src="images/deployments/arch-deploy-service-sync-directory.png"
              srcset="images/deployments/arch-deploy-service-sync-directory.svg" class="wot-arch-diagram"
              alt="service sync directory" />
            <figcaption>Multiple Cloud Connections Through Thing Description
              Directory Synchronization</figcaption>
          </figure>
        </section>
        <section id="sec-deployment-service-sync-proxy">
          <h3>Connection Through Proxy Synchronization</h3>
          <p> In <a href="#deployment-service-sync-intermediary"></a>, two remote <a>Intermediaries</a>
            synchronize device information. When a shadow of <a>Thing</a>
            B is created in remote <a>Intermediary</a> B, the TD of the shadow is
            simultaneously synchronized into remote <a>Intermediary</a> A.
            Remote <a>Intermediary</a> A in turn creates its own shadow of
            <a>Thing</a> B, and registers the TD with <a>Thing Description Directory</a>
            A. With this mechanism, synchronization between
            <a>Thing Description Directory</a> services is not necessary.
          </p>
          <figure id="deployment-service-sync-intermediary">
            <img src="images/deployments/arch-deploy-service-sync-intermediary.png"
              srcset="images/deployments/arch-deploy-service-sync-intermediary.svg" class="wot-arch-diagram"
              alt="service sync intermediary" />
            <figcaption>Multiple Cloud Connections Through
              Intermediary Synchronization</figcaption>
          </figure>
        </section>
      </section>
    </section>
  </section>

  <section id="sec-security-considerations">
    <h1>Security Considerations</h1>
    <p>
      Security is a cross-cutting issue that needs to be considered
      in all <a href="#sec-building-blocks">WoT
        building blocks</a> and WoT implementations. This chapter
      summarizes some general issues and guidelines to help
      preserve the security of concrete WoT implementations.
      However, these are only general guidelines and an abstract architecture
      such as described in this document cannot, itself, guarantee security.
      Instead the details of a concrete implementation need to be considered.
      For a more detailed and complete analysis of security (and
      privacy) issues, see the <em>WoT Security and Privacy Guidelines</em>
      document [[?WOT-SECURITY]].
    </p>
    <p>Overall, the goal of the WoT is to describe the existing
      access mechanisms and properties of IoT devices and
      services, including security. In general, W3C WoT is
      designed to describe what exists rather than to prescribe
      what to implement. A description of an existing system
      should accurately describe that system, even if it has
      less than ideal security behavior. A clear understanding of
      the security vulnerabilities of a system supports
      security mitigations&mdash;although of course such data need
      not be distributed to those who might maliciously exploit it.
    </p>
    <p>
      However, especially for new systems,
      the WoT architecture should <em>enable</em> the use
      of best practices.
      In general, the WoT security
      architecture must support the goals and mechanisms of the
      IoT protocols and systems it connects to. These systems vary
      in their security requirements and risk tolerance, so
      security mechanisms will also vary based on these factors.
    </p>
    <p>Security is especially important in the IoT
      domain since IoT devices need to operate autonomously and, in
      many cases, may be in control of safety-critical systems.
      IoT devices are subject to different and in some
      cases higher risks than IT systems. It is also important to
      protect IoT systems so that they cannot be used to launch
      attacks on other computer systems.
    </p>
    <p>In general, security cannot be guaranteed. It
      is not possible for the WoT to turn an insecure system into
      a secure one. However, the WoT architecture needs to do
      no harm: it should support security at least as
      well as the systems it describes and supports.
    </p>
    <section id="sec-security-consideration-td-risks">
      <h2>WoT Thing Description Risks</h2>
      <p>
        The metadata contained in a <a>WoT Thing Description</a>
        (TD) is potentially sensitive. As a best practice, TDs
        should be used together with appropriate integrity protection
        mechanisms and access control policies, with the goal of 
        providing it only to authorized users.
      </p>
      <p>Please refer to the Privacy Considerations 
        sections of the WoT Thing Description
        specification for additional details and discussion of
        these points.</p>
      <section id="sec-security-consideration-td-private">
        <h5>Thing Description Private Security Data Risk</h5>
        <p>
          TDs are designed to carry only <a>Public Security Metadata</a>.
          The built-in TD security schemes defined in the
          TD specification intentionally do not support the encoding of
          <a>Private Security Data</a>. 
	  However, there is a risk that
          other fields such as
          human-readable descriptions might be misused
          to encode this information, or new
          security schemes might be defined and deployed via
          the extension mechanism that encode such
          information.
        </p>
        <dl>
          <dt>Mitigation:</dt>
	  <dd>
	  <span class="rfc2119-assertion" id="arch-security-consideration-separate-security-data">
          There SHOULD be a strict separation of
          <a>Public Security Metadata</a> and <a>Private Security Data</a>.</span>
	  <span class="rfc2119-assertion" id="arch-security-consideration-auth-private-data">
	  Authentication and authorization 
	  SHOULD be established based on separately managed <a>Private Security Data</a>.</span>
	  <span class="rfc2119-assertion" id="arch-security-consideration-no-private-security-data">
          <a>Producers</a> of TDs MUST ensure that no <a>Private
          Security Data</a> is included in <a>TDs</a>.</span>
	  </dd>
        </dl>
      </section>
      <section id="sec-security-consideration-td-cm">
        <h5>Thing Description Communication Metadata Risk</h5>
        <p>
	  Without best-practice configuration of security mechanisms, communication
	  with IoT devices is at greater risk of being intercepted or compromised.
	  <!-- Following is true, but doesn't really fit here.
          Due to the
          automation of network interactions necessary to
          deploy IoT at scale, operators need to ensure that <a>Things</a>
          are exposed and consumed in a way that is compliant
          with their security policies.
	  -->
        </p>
        <dl>
          <dt>Mitigation:</dt>
          <dd>
          Configure any communication security metadata for an
	  <a>IoT Platform</a> used with WoT following
	  best practices for that <a>IoT Platform</a>.
	  <span class="rfc2119-assertion" id="arch-security-consideration-communication-binding">
            Whenever possible, TD creators SHOULD use the vetted communication
            metadata provided in the <a>WoT Binding Templates</a>.</span>
	  <span class="rfc2119-assertion" id="arch-security-consideration-communication-platform">
            When generating TDs for an <a>IoT
		  Platform</a> not covered by the <a>WoT Binding
              Templates</a>, TD creators SHOULD ensure that all the security
            requirements of the <a>IoT Platform</a> are
            satisfied.</span>
          </dd>
        </dl>
      </section>
    </section>
    <section id="sec-security-consideration-scripting-risks">
      <h2>WoT Scripting API Risks</h2>
      <p>
        The <a>WoT Runtime</a> implementation and the <a>WoT
          Scripting API</a> should have mechanisms to prevent
        malicious access to the system and isolate scripts in
        multi-tenant <a>Servients</a> . More specifically the <a>WoT
          Runtime</a> implementation when used with the <a>WoT
          Scripting API</a> should consider the following
        security and privacy risks and implement the recommended
        mitigations.
      </p>
      <p>
	In general, 
	these risks and mitigations should also be applied to any system
	that supports programmable behavior for WoT systems,
	not just the <a>WoT Scripting API</a>.
      </p>
      <section id="sec-security-consideration-cross-script">
        <h5>Cross-Script Security Risk</h5>
        <p>
          In basic WoT setups, all scripts running inside the
          <a>WoT Runtime</a> are considered trusted,
          distributed by the manufacturer, and therefore there
          is no strong need to isolate
          script instances from each other. However,
          depending on device capabilities, deployment use
          case scenarios, and risk level it might be desirable
          to do so. For example, if one script handles
          sensitive data and is
          well-audited, it might be desirable to separate it
          from the rest of the script instances to minimize
          the risk of data exposure in case some other script
          inside the same system gets compromised during runtime. Another
          example is mutual co-existence of different tenants
          on a single WoT device. In this case each WoT
          runtime instance will be hosting a different tenant,
          and preventing tenants from accessing each other's data
          without authorization will generally be needed.
        </p>
        <dl>
          <dt>Mitigation:</dt>
          <dd>
	    <span class="rfc2119-assertion" id="arch-security-consideration-isolation-sensitive">
            The <a>WoT Runtime</a> SHOULD perform isolation of
            script instances and their data from each other in cases when
            scripts handle sensitive data.</span>
	    <span class="rfc2119-assertion" id="arch-security-consideration-isolation-tenants">
	    Similarly, the <a>WoT Runtime</a>
            implementation SHOULD perform isolation of <a>WoT
              Runtime</a> instances and their data from each other if a WoT
            device has more than one tenant.</span>
      In practice, isolation of scripts and runtime instances from each other
      can be accomplished by running all instances
      in a "sandboxed" environment that controls its access to the rest of the environment.
      For more information see Sections 
      <a href="https://www.w3.org/TR/wot-security/#wot-servient-single-tenant">WoT Servient Single-Tenant</a> 
      and <a href="https://www.w3.org/TR/wot-security/#wot-servient-multi-tenant">WoT Servient Multi-Tenant</a>
      of the <em>WoT Security and Privacy Guidelines</em> specification [[?WOT-SECURITY]].
          </dd>
        </dl>
      </section>
      <section id="sec-security-consideration-device-direct-access">
        <h5>Physical Device Direct Access Risk</h5>
        <p>In case a script is compromised or malfunctions
          the underlying physical device (and potentially
          surrounded environment) can be damaged if a script
          can use directly exposed native device interfaces.
          If such interfaces lack safety checks on their
          inputs, they might bring the underlying physical
          device (or environment) to an unsafe state.
        </p>
        <dl>
          <dt>Mitigation:</dt>
          <dd><p>
	    In order to reduce
            the damage to a physical WoT device in cases a
            script gets compromised, it is important to
            minimize the number of interfaces that are
            exposed or accessible to a particular script
            based on its functionality.
	    <span class="rfc2119-assertion" id="arch-security-consideration-avoid-direct">
            The <a>WoT Runtime</a> SHOULD NOT directly
            expose low-level device hardware interfaces to the
            script developers.</span>
		  </p><p>
      Hardware abstraction layers can provide an additional level of protection.
      Hardware abstraction layers are software components that mediate the interaction between the 
      application and the hardware and can be as simple as a software library,
      although more sophisticated implementations may be implemented as drivers
      accessible through system calls or supported by hypervisors.  The more 
      sophisticated versions of hardware abstraction layers can prevent applications from bypassing them.
		  
	    <span class="rfc2119-assertion" id="arch-security-consideration-use-hal">
	    A <a>WoT Runtime</a>
            implementation SHOULD provide a hardware
            abstraction layer for accessing the low-level device hardware interfaces.</span>
		  
	    <!-- <span class="rfc2119-assertion" id="arch-security-consideration-hal-refuse-unsafe"> -->
	    Hardware abstraction
            layers should refuse to execute commands that
            might put the device (or environment) to an
            unsafe state.<!-- </span> -->
      Such "software interlocks" should not be the only mechanism preventing 
      a system from entering an unsafe state.  Ideally, multiple layered safety
      controls should be used, including both software and hardware interlocks.
	</p>
          </dd>
        </dl>
      </section>
    </section>
    <section id="sec-security-consideration-runtime-risks">
      <h2>WoT Runtime Risks</h2>
      <section id="sec-security-consideration-update-provisioning">
        <h5>Provisioning and Update Security Risk</h5>
        <p>
          If the <a>WoT Runtime</a> implementation supports
          post-manufacturing provisioning or updates of
          itself, scripts, or any related data (including
          security credentials), it can be a major attack
          vector. An attacker can try to modify any above
          described element during the update or provisioning
          process or simply provision attacker's code and data
          directly.
        </p>
        <dl>
          <dt>Mitigation:</dt>
          <dd>
	    <span class="rfc2119-assertion" id="arch-security-consideration-secure-update">
            Post-manufacturing provisioning or update of
            scripts, the <a>WoT Runtime</a> itself or any
            related data SHOULD be done in a secure fashion.</span>
            A set of recommendations for secure update and
            post-manufacturing provisioning can be found in
            the <em>WoT Security and Privacy Guidelines</em>
            specification [[?WOT-SECURITY]].
          </dd>
        </dl>
      </section>
      <section id="sec-security-consideration-credentials-storage">
        <h5>Security Credentials Storage Risk</h5>
        <p>
          Typically the <a>WoT Runtime</a> needs to store the
          security credentials that are provisioned to a WoT
          device to operate in a network. If an attacker can
          compromise the confidentiality or integrity of these
          credentials, then it can obtain access to
          assets, impersonate other WoT Things, devices, or services,
          or launch
          Denial-Of-Service (DoS) attacks.
        </p>
        <dl>
          <dt>Mitigation:</dt>
          <dd>
	    <span class="rfc2119-assertion" id="arch-security-consideration-secure-cred-storage">
            The <a>WoT Runtime</a> SHOULD securely store any
            provisioned security credentials, guaranteeing
            their integrity and confidentiality.</span>
	    <span class="rfc2119-assertion" id="arch-security-consideration-secure-cred-isolation">
	    In case
            there are more than one tenant on a single
            WoT-enabled device, a <a>WoT Runtime</a>
            implementation SHOULD isolate
            each tenant's provisioned security credentials
            from other tenants.</span>
	    <span class="rfc2119-assertion" id="arch-security-consideration-no-expose-cred">
            In order to minimize a risk that
            provisioned security credentials get
            compromised, the <a>WoT Runtime</a>
            implementation SHOULD NOT expose any API for
            scripts to query provisioned security
            credentials.</span>
	    <span class="rfc2119-assertion" id="arch-security-consideration-limit-cred-access">
	    Such credentials (or even better,
            abstract operations that use them but do not
            expose them) SHOULD only be accessible to the underlying 
            protocol implementation that uses them.</span>
          </dd>
        </dl>
      </section>
    </section>
    <section id="sec-security-consideration-trusted-environment-risks">
      <h2>Trusted Environment Risks</h2>
      <p>
      In section
      <a href="#sec-common-deployment-patterns"></a>
      several usage scenarios are presented
      that include the concept of a <a>Trusted Environment</a> and a security 
      boundary. Entities that are members of a <a>Trusted Environment</a>
      all share access to a common set of resources (such as a local
      network) and are implicitly granted certain access rights to
      each other.  A common example would be a WiFi LAN in the home
      where access to the WEP password allows devices to communicate
      with each other without any further access controls.
      Allowing implicit access rights like this and using a single
      shared secret for a large number of entities means that a single
      malicious actor with access to the <a>Trusted Environment</a> can
      cause significant damage.
      </p>
      <p>
      One common IoT situation is the use of an HTTP/HTML browser to
      access locally hosted web services in a home environment.
      Such locally hosted web services may not have a publicly
      visible URL and so are not able to participate in the 
      CA system expected by browsers to enable use of HTTP/TLS (HTTPS).
      It is often the case in this situation that plain HTTP is used
      and the only security protecting the communication is network 
      encryption, for example WEP, which is relatively weak.
      </p>
      <dl>
        <dt>Mitigation:</dt>
        <dd>
	<span class="rfc2119-assertion" id="arch-security-consideration-limit-trust">
	Trust relationships SHOULD be as restricted as possible,
	ideally pairwise and limited to precisely the access
	required.</span>
	As noted, in some situations this is difficult to manage and
	implicit access such as described is used, and may even be 
	assumed by certain entities, such as browsers.
	<span class="rfc2119-assertion" id="arch-security-consideration-segmented-network">
	In the case of implicit access control via access to a common network
	a segmented network SHOULD be used.</span>
	For example, in the home environment,
	a separate network can be used for IoT devices.
<!-- following not strictly true as guest networks often do not allow inter-device communication
  , and routers
	often provide a "guest" network that can be used for this purpose.
-->
	<!-- <span class="rfc2119-assertion" id="arch-security-consideration-use-psk"> -->
	In commercial and industrial environments, 
	explicit installation of <!-- pre-shared
	keys --> certificates should be used to allow browsers to access local services
	while using TLS.
  <!-- </span> -->
  Certificates support secure authentication and are required to enable TLS.
  Once TLS is enabled other security mechanisms that assume secure transport, 
  such as API keys or passwords,
	can be used to provide fine-grained access control.
	Note that using a single key for a large number of services is
	equivalent to the "implicit access" situation above.  
        </dd>
      </dl>
    </section>
    <section id="sec-security-consideration-secure-transport">
      <h2>Secure Transport</h2>
      <p>
      As noted in
      <a href="#sec-security-consideration-trusted-environment-risks"></a>,
      there are situations in which secure transports, such as TLS, are not
      feasible or are difficult to set up, such as on a local LAN within a home.
      Unfortunately, generally access control mechanisms in HTTP 
      are designed to be used with secure transport and can be 
      easily bypassed without it.  In particular, it is relatively easy to
      capture passwords and tokens from unencrypted protocol interactions
      which can be intercepted by a third party.  Also, man-in-the-middle
      attacks can be easily implemented without TLS providing server authentication. 
      </p>
      <dl>
        <dt>Mitigation:</dt>
        <dd>
          <p>
            Because of the practical difficulties in setting up secure transport in all
            situations, we cannot make a blanket assertion that it is always 
            required.  Instead we provide a set of requirements for different use
            cases:
          </p>
          <dl>
          <dt>Public Networks:</dt>
          <dd><span class="rfc2119-assertion" 
              id="arch-security-consideration-tls-mandatory-pub">When a Thing is made 
            available on the public internet so it can
            be accessed by anyone, from anywhere, then it MUST be protected by secure
            transport such as TLS or DTLS.</span>
            A Thing available on the public internet will have a public
            URL and so normal CA mechanisms to provide certificates are available.
            This should be done even if there are no access controls on the endpoint,
            for example when providing a publicly accessible service,
            because secure transport also protects the privacy of requesters
            (for example, the content of queries).
          </dd>
          <dt>Private Networks:</dt>
          <dd><span class="rfc2119-assertion" 
              id="arch-security-consideration-tls-recommended-priv">When a Thing is made 
            available on a private network then it SHOULD be protected by secure
            transport such as TLS or DTLS.</span>
          The risk increases with the sensitivity of the data being protected,
          the potential for damage, and with the number of people given access 
          to the private network. 
          Secure transport is a higher priority in higher risk situations such 
          as a factory network; 
          in such cases, it is also more practical to install pre-shared keys.
          In low-risk situations, the following is permissible:
          <span class="rfc2119-assertion" 
              id="arch-security-consideration-tls-optional-on-lan">
           Private networks such as a LAN, protected by a firewall, MAY use the 
           <a href="#sec-security-consideration-trusted-environment-risks">Trusted 
           Environment</a> approach of depending on network security only.</span>
           This is not generally recommended but may be necessary for practical
           reasons.  Please see the referenced security consideration for
           additional risks and mitigations with this approach. 
          </dd>
          <dt>Brownfield Devices:</dt>
          <dd>WoT is descriptive and an accurate description of existing
           "brownfield" devices may reveal they are not secure.  
           For example, a specific
           device may use HTTP without TLS, which is not secure even if it 
           uses access controls such as a password.
           It is often not possible to upgrade such devices to support stronger
           security.
           In these cases, the above two mitigations still apply.  If exposed
           on a private network, the 
           <a href="#sec-security-consideration-trusted-environment-risks">Trusted 
           Environment</a> approach should be used, with access limited as much
           as possible.
           If it is desired to expose such a device on the public internet,
           additional steps should be taken the enhance its security.  In particular,
           a proxy can be used to ensure that communications over the public
           network use secure transport.  A proxy can also be used to provide
           access controls.
          </dd>
          </dl>
          <p>
          <span class="rfc2119-assertion" 
              id="arch-security-consideration-tls-1-3">
            When secure transport over TCP is appropriate,
            then at least TLS 1.3 [[RFC8446]]
            SHOULD be used.</span>
          <span class="rfc2119-assertion" 
              id="arch-security-consideration-tls-1-2">
            If TLS 1.3 cannot be used for compatibility reasons
            but secure transport over TCP is appropriate,
            TLS 1.2 [[RFC5246]]
            MAY be used.</span>
          <!-- <span class="rfc2119-assertion" 
              id="arch-security-consideration-dtls-1-3"> 
            This was downgraded from an assertion due to lack of testing
            (problem with availablity of libraries).  However, it is still
            a good idea to use DTLS 1.3 when available.
          -->
            When secure transport over UDP is appropriate,
            then at least DTLS 1.3 [[RFC9147]]
            is recommended, if possible.
          <!-- </span> -->
          <span class="rfc2119-assertion" 
              id="arch-security-consideration-dtls-1-2">
            If DTLS 1.3 cannot be used for compatibility reasons
            but secure transport over UDP is appropriate,
            then DTLS 1.2 [[RFC6347]]
            MAY be used.</span>
          <span class="rfc2119-assertion"
              id="arch-security-consideration-no-earlier-tls-or-dtls">
            Versions of DTLS or TLS earlier than 1.2 MUST NOT be used for 
            new development.
          </span>
          Existing Things using earlier versions of TLS or DTLS can be 
          described by WoT metadata (e.g. Thing Descriptions) but should
          be considered insecure.
          </p>
          <p>Additional considerations apply if a Thing can reveal
          <a>Personally Identifiable Information</a> (PII).
          See <a href="#arch-privacy-consideration-access-controls"></a>.
        </dd>
      </dl>
    </section>
  </section>
  <section id="sec-privacy-considerations">
    <h1>Privacy Considerations</h1>
    <p>
      Privacy is a cross-cutting issue that needs to be considered
      in all <a href="#sec-building-blocks">WoT
        building blocks</a> and WoT implementations. This chapter
      summarizes some general issues and guidelines to help
      preserve the privacy of concrete WoT implementations.
      However, these are only general guidelines and an abstract architecture
      such as described in this document cannot, itself, guarantee privacy.
      Instead the details of a concrete implementation need to be considered.
      For a more detailed and complete analysis of privacy (and security) issues, 
      see the <em>WoT Security and Privacy Guidelines</em>
      specification [[?WOT-SECURITY]].
    </p>
    <section id="sec-privacy-consideration-td-risks">
      <h2>WoT Thing Description Risks</h2>
      <p>
        The metadata contained in a <a>WoT Thing Description</a>
        (TD) is potentially sensitive, and even if it does
	      not explicitly contain <a>Personally Identifiable Information</a> (PII)
	it may be possible to infer PII from it. As a best practice, TDs
        should be used together with appropriate integrity protection
        mechanisms and access control policies, with the goal of 
        providing it only to authorized users.
	In general, many of the <a href="#sec-security-considerations">Security Considerations</a>
	discussed in the previous section can also be seen as privacy risks, when
	they relate the undesired an unauthorized disclosure of information.
      </p>
      <p>Please refer to the Privacy Considerations 
        sections of the WoT Thing Description
        specification for additional details and discussion of
        these points.</p>
      <section id="sec-privacy-consideration-td-pii">
        <h5>Thing Description Personally Identifiable
          Information Risk</h5>
        <p>Thing descriptions can potentially contain
          <a>Personally Identifiable Information</a> (PII) of various
          types. Even if it is not explicit,
          a TD and its association with an identifiable person
          can be used to infer information about
          that person. For example, the association of
          fingerprintable TDs exposed by mobile devices
          whose location can be determined can be a tracking
          risk. Even if a particular device instance cannot
          be identified, the type of device represented
          by a TD, when associated with a person, may constitute
          personal information. For example, a medical device
          may be used to infer that the user has a medical condition.
        </p>
	<p>Generally, <a>Personally Identifiable Information</a> in
          a TD should be limited as much as possible. In some
          cases, however, it cannot be avoided. The potential
          presence of both direct and inferencable
          PII in a TD means that TD as a whole should be
          treated like other forms of PII. They should be
          stored and transmitted in a secure fashion, should
          only be provided to authorized users, should
          only be cached for limited times, should be deleted
          upon request, should only be used for the purpose
          for which they were provided with user consent, and
          they should otherwise satisfy all requirements
          (including any legal requirements) for
          the use of PII.</p>
        <dl>
          <dt>Mitigation:</dt>
          <dd>
	    <span class="rfc2119-assertion" id="arch-privacy-consideration-min-explicit-pii">
	    Storage of explicit PII in TDs SHOULD be minimized
            as much as possible.</span>
	    Even without explicit PII
            in TDs, a tracking and identification privacy
            risk may exist. 
	    <span class="rfc2119-assertion" id="arch-privacy-consideration-explicit-pii"> 
	    TDs that can be associated with a person
	    SHOULD generally be treated as if they contained PII and
            subject to the same management policies as other PII, even if they
	    do not explicitly contain it.</span>
	    <span class="rfc2119-assertion" id="arch-privacy-consideration-dist-td-auth"> 
	    Distribution mechanisms for TDs SHOULD ensure they are 
	    only provided to authorized Consumers.</span>
	    Note that the <a>WoT Discovery</a> mechanism is designed to address these
	    specific issues, as long as it is used with authentication and access
	    controls on exploration services.
	    <!--span class="rfc2119-assertion" id="arch-privacy-consideration-no-unness-info-td" -->
      As a general matter of policy,
            unnecessary information
            should not be exposed in TDs whenever possible.<!-- </span> -->
            For example, explicit type and instance identifying information in TDs should
            only be included if it is needed by the use case.
            Even if required by the use case,
            to minimize tracking risks, distributed and limited-scope
            identifiers should be used whenever possible rather than
            globally unique identifiers.
            Other forms of information,
            such as human-readable descriptions, may also
            be omitted in some use cases to reduce fingerprinting risks.
          </dd>
        </dl>
      </section>
    </section>
    <section id="arch-privacy-consideration-access-controls">
      <h2>Access to Personally Identifiable Information</h2>
      <p>In addition to the risks of revealing <a>Personally Identifiable Information</a> (PII) through metadata
      discussed in <a href="#sec-privacy-consideration-td-pii"></a>,
      the data returned by Things can itself be sensitive.
      For example, a Thing could be monitoring the location or
      health of a specific person.  Information associated with a 
      person should be treated as PII even if it is not immediately
      obvious that it is sensitive, since it could be combined with
      other information to reveal sensitive information.
      </p>
      <dl>
        <dt>Mitigation:</dt>
        <dd>
	      <span class="rfc2119-assertion" id="arch-privacy-consideration-access-control-mandatory-person">
Things returning data or metadata (such as TDs) associated with a person SHOULD use some form of access control.</span>
      A special case of this is a <a>Thing Description Directory</a>,
      as described in [[WOT-DISCOVERY]], which is a Thing that returns 
      Thing Descriptions as data.  Such directory services are included
      in the above statement and 
      should use access control if the TDs describe Things associated with
      identifiable people.  In the case of services
      returning Thing Descriptions, the following also applies: 
	      <span class="rfc2119-assertion" id="arch-privacy-consideration-id-access-control-mandatory-immutable">
Services returning Thing Descriptions with immutable IDs SHOULD use some form of access control.</span>
<!--
      Specifically, in both of these situations, the <code>nosec</code> security
      scheme described in [[WOT-THING-DESCRIPTION]] should not be used,
      as it provides no access control.
-->
      Following the principle that Thing Descriptions describing
      Things associated with specific persons should be treated as
      PII, even if they do not explicitly contain it, this implies
      that directories providing such TDs should use access control.
      Generally speaking, 
      the only exceptions should be cases where access is controlled
      by another mechanism not described in the TD itself, such as a 
      segmented network.
      Again it should also be noted that access controls are generally only
      effective when secure transport is also used;
      see <a href="#sec-security-consideration-secure-transport"></a>.
      Use of access controls without secure transport, at best,
      only discourages casual access by unauthorized parties.
        </dd>
     </dl>
	  </section>
  </section>

  <section id="sec-accessibility-considerations" class="informative">
    <h1>Accessibility Considerations</h1>
    <p>
    IoT generally and WoT in particular provide both opportunties and challenges for 
    accessibilty.
    On the one hand, network access to internet-enabled devices' functionality
    makes it possible to build alternative interfaces to that functionality,
    both web-based and physical,
    that are not limited by the devices' own hardware.
    Such interfaces can and
    should follow best practices for accessibility.
    On the other hand, 
    IoT devices are diverse, are often cost and space limited,
    and situations where they do need to rely on their
    own hardware for interfacing, 
    such as during onboarding before a network connection is established, 
    can be challenging to make accessible.
    </p>
    <p>
    There are two situations to consider for WoT regarding accessibility:
    greenfield devices designed from the beginning to be used with WoT,
    and brownfield devices where WoT is used only to describe an existing
    system.
    </p>
    <p>
    A number of use cases that relate to accessibilty are covered in 
    The <em>WoT Use Cases and Requirements</em> document [[WOT-USE-CASES-REQUIREMENTS]].
    </p>
    <section id="sec-accessibility-considerations-greenfield">
    <h2>Greenfield WoT Systems</h2>
    <p>
    Ideally, accessibility should be thought of from the beginning of the development 
    of a component in any greenfield WoT system. 
    If the component's hardware has its own display or other form of
    physical user interface, this must be as accessible as possible.
    If it cannot be made accessible (for example, due to screen size limitations),
    then equivalent functionality should be made available over the network
    so an accessible interface (such as a web or voice interface) can be used instead.
    When the component is accessed over the network, provisions must be 
    made for accessible web interfaces whether hosted directly on the 
    device or provided by another component (such as a dashboard).
    Situations where the on-board hardware is the only option for interfaces,
    such as during onboarding, should be carefully designed to be made
    as accessible as possible.
    </p>
    <ul>
    <li>
        For web-based user interfaces, 
        relevant guidance on accessibility can be found in 
        W3C Web Content Accessibility Guidelines [[WCAG22]].</li>
    <li>More generally, EN 301 549 [[etsi-en-301-549]]
        provides guidelines for hardware and other user interfaces, 
        especially for software/firmware running on "closed functionality" devices.</li>
    </ul>
    <p>
    In general, 
    a Thing should always have at least one user interface 
    (either direct or network-based) that is fully accessible according 
    to WCAG and EN 301 549.
    Accessibility must be applied to the interfaces made available for
    all types of users: 
    manufacturers, installers, device owners, end users.
    </p>
    <p>
    The accessibility status of the user interfaces for a Thing should be declared in the Thing’s metadata, 
    so that users can pick the user interface that is most appropriate for them.
    If the Thing has a web interface, existing mechanisms to describe
    web interfaces should be used.
    To better support the connection between the web and physical interfaces,
    affordances described in a WoT Thing Description should be 
    annotated in such a way that their relation to the physical interface
    on the device can be understood.
    </p>
    <p>
    Components that do not directly offer a user interface 
    must still support accessibility by providing suitable data and functions. 
    For example, developers of public Things (e.g. a ticket machine or an ATM) should consider 
    a locator function by which a user can physically identify and locate the Thing by auditory, 
    visual or other signaling.
    </p>
    </section>
    <section id="sec-accessibility-considerations-brownfield">
    <h2>Brownfield WoT Systems</h2>
    <p>
    Brownfield applications of WoT cover situations where WoT metadata is used to 
    describe an existing device, but WoT was not considered during its design.
    In this case many of the above provisions still apply.  
    For example, a web interface provided by another system to monitor or control the device 
    should follow the guidelines in WCAG,
    and the Thing Description should annotate affordances appropriately.
    If a device's own physical interface provides an accessibility challenge,
    there is the potential to overcome it with an alternative interface based
    on its network affordances.
    </p>
    </section>
  </section>

  <section id="changes" class="appendix">
    <h1>Recent Specification Changes</h1>
      <h2 id="changes-from-pr">Changes from 11 July 2023 Proposed Recommendation</h2>
      <ul>
      <li>No normative changes from Proposed Recommendation.</li>
      <li>Add errata link.</li>
      <li>Update former editor's organization name.</li>
      <li>Update process link to 3 November 2023.</li>
      <li>Update acknowledgements.</li>
      <li>Update references to IEC-FOTF document, WCAG 2.2 document, and other WoT documents.</li>
      <li><a href="https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2F2023%2FPR-wot-architecture11-20230711%2F&doc2=https%3A%2F%2Fraw.githubusercontent.com%2Fw3c%2Fwot-architecture%2Fmain%2Fpublication%2Fver11%2F5-rec%2FOverview.html">HTML Diff</a></li>
      </ul>
    <h2 id="changes-from-cr">Changes from 19 January 2023 Candidate Recommendation</h2>
      <ul>
      <li>No normative changes from Candidate Recommendation.</li>
      <li>At-risk assertions that did not receive sufficient implementations were removed or
          converted to informative statements.</li>
<!--
      <li><a href="https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2F2023%2FCR-wot-architecture11-20230119%2F&doc2=https%3A%2F%2Fw3c.github.io%2Fwot-architecture%2Fstatic.html">HTML Diff</a></li>
-->
      <li><a href="https://w3c.github.io/wot-architecture/publication/ver11/4-pr/diff.html">HTML Diff</a></li>
      </ul>
    <h2 id="changes-from-wd-2022-09-07">Changes from the WD published September 7, 2022</h2>
    <ul>
      <li>Modify <a href="#sec-building-blocks">Section 7, WoT Building Blocks</a> so that it is informative.</li>
      <li>Add terminology entries for Profile, System, and Directory.</li>
      <li>Updates to affiliation of Matthias Kovatsch (as a former editor).</li>
      <li>Add/update references to the WoT Use Cases and Requirements [[WOT-USE-CASES-REQUIREMENTS]] document.</li>
    </ul>

    <h2 id="changes-from-fpwd-1.1">Changes in WD published September 7, 2022 from the FPWD version</h2>
    <ul>
      <li>Move Toru Kawaguchi to former editors.</li>
      <li>Update abstract to reflect use of prescription (as opposed to pure description) where necessary.</li>
      <li>New section under Terminology: Device Categories.</li>
      <li>Section removed: System Integration.</li>
      <li>Lifecycle section reworked; removal of separate "Information Lifecycle" section.</li>
      <li>Reference and discuss new WoT building block and document: WoT Discovery [[WOT-DISCOVERY]]</li>
      <li>Update discussion of WoT Profiles [[WOT-PROFILE]]</li>
      <li>Update discussion of WoT Binding Templates [[?WOT-BINDING-TEMPLATES]]</li>
      <li>Rename "System Topologies (Horizontals)" to "Common Deployment Patterns".</li>
      <li>Rename "Application Domains (Verticals)" to "Application Domains".</li>
      <li>New or revised deployment patterns:
        <ul>
          <li>Telemetry</li>
          <li>Orchestration</li>
          <li>Virtual Things</li>
        </ul>
      </li>
      <li>Revise Security Considerations and Privacy Considerations: 
       <ul>
          <li>Reorganized to ensure that risks and mitigations are presented separately, 
          and that normative content is only given under mitigations.</li>
          <li>Added new section for Access to PII covering actual data access, not just metadata.</li>
          <li>Added new section for Trusted Environments.</li>
          <li>Added new section for Secure Transport. This section defines under what
              conditions (D)TLS should or must be used.</li>
        </ul>
    </ul>

    <h2 id="changes-in-fpwd-1.1-from-recommendation-1.0">Changes in the FPWD from the 1.0 version of [[wot-architecture]]</h2>
    <ul>
      <li>Make Security Considerations and Privacy Considerations normative.</li>
      <li>Add definitions for Connected Device (a.k.a. Device), Service, and Shadow.  
	  Update definitions for
	  Virtual Thing and Digital Twin.  
	  Narrow definition of Virtual Thing to
	  a Service that mediates with one of more other Things.</li>
      <li>Split Security and Privacy Considerations into separate chapters.</li>
      <li>New chapter: Lifecycle.</li>
      <li>New terminology: Thing Model.</li>
      <li>Chapter restructuring and renaming:
        <ul>
          <li>Application Domains (Verticals)</li>
          <li>System Topologies (Horizontals)</li>
          <li>System Integration</li>
          <li>Abstract WoT System Architecture</li>
        </ul>
      </li>
      <li>Various editors notes with placeholders for planned contributions.</li>
      <li> References to github repositories for use cases and requirements.</li>
      <li>Requirement chapter was moved to the <em>WoT Use Cases and Requirements</em> document [[WOT-USE-CASES-REQUIREMENTS]].</li>
    </ul>

  </section>

    <section id="acknowledgements" class="appendix normative">
        <h1>Acknowledgments</h1>
        <p>Special thanks to 
              Kazuo Kajimoto,
              Toru Kawaguchi,
             and
              Matthias Kovatsch 
           for co-editing and many significant contributions
	         to the initial version of the WoT architecture specification.
	      Special thanks to 
            Cristiano Aguzzi,
            Andrea Cimmino Arriaga,
            Kazuyuki Ashimura,
            Luca Barbato,
            Ben Francis,
            Christian Glomb,
            Klaus Hartke, 
            Sebastian Käbisch, 
            Takuki Kamiya, 
            Ari Keränen, 
            Zoltan Kis, 
            Ege Korkan, 
            Michael Koster, 
            Philippe Le Hegaret, 
            Kazuaki Nimura, 
            Daniel Peintner,
            James Pullen,
            Elena Reshetova, 
           and
            Farshid Tavakolizadeh
        for their contributions to this document.
        </p>
        <p>
          Special thanks to Dr. Kazuyuki Ashimura from the W3C for the continuous help and support
          of the work of the WoT Architecture Task Force.
        </p>
        <p>
            Many thanks to the W3C staff and all other active Participants of the W3C Web
            of Things Interest Group (WoT IG) and Working Group (WoT WG) for their
            support, technical input and suggestions that led to improvements to
            this document.
        </p>
        <p>The WoT WG also would like to appreciate the pioneering efforts
           regarding the concept of "Web of Things" that started as an academic
           initiative in the form of publications such as [[?WOT-PIONEERS-1]] [[?WOT-PIONEERS-2]]
           [[?WOT-PIONEERS-3]] [[?WOT-PIONEERS-4]] and, starting
           in 2010, an
           <i>International Workshop on the Web of Things</i>.</p>
           <p>Finally, special thanks to Joerg Heuer for leading the WoT IG for 2 years
            from its inception and guiding the group to come up with the concept of
            WoT building blocks including the Thing Description.</p>
    </section>

</body>

</html>