Copyright © 2017-2020 W3C ® ( MIT , ERCIM , Keio , Beihang ). W3C liability , trademark and permissive document license rules apply.
The W3C Web of Things (WoT) is intended to enable interoperability across IoT platforms and application domains.
This WoT Discovery specification...
To do.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
To do.
This document was published by the Web of Things Working Group as an Editor's Draft.
GitHub Issues are preferred for discussion of this specification. Alternatively, you can send comments to our mailing list. Please send them to public-wot-wg@w3.org ( archives ).
Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
This document is governed by the 1 March 2019 W3C Process Document .
To Do.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY , MUST , and SHOULD in this document are to be interpreted as described in BCP 14 [ RFC2119 ] [ RFC8174 ] when, and only when, they appear in all capitals, as shown here.
This section is non-normative.
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.
id
attribute).
This section is non-normative.
Examples of why we need discovery.
This section is non-normative.
The WoT discovery process should have the following capabilities:
This section is non-normative.
This section is non-normative.
This section is non-normative.
This section is non-normative.
This section is non-normative.
This section is non-normative.
This section is non-normative.
Two-Phase approach.
Description of supported introductions, and requirements for new introduction mechanisms.
Any
mechanism
that
results
in
a
single
URL.
This
includes
Bluetooth
beacons,
QR
codes,
and
written
URLs
to
be
typed
by
a
user.
A
GET
on
all
such
URLs
MUST
result
in
a
TD.
For
self-describing
Things,
this
can
be
the
TD
of
the
Thing
itself.
If
the
URL
references
a
Directory,
this
MUST
be
the
TD
of
the
Directory
service.
A
Directory
can
be
distinguished
from
a
Thing
by
the
use
of
an
@type
including
the
semantic
term
Directory
.
To Do.
To Do.
To Do.
Description of supported explorations, and requirements for new exploration mechanisms.
Mechanism for devices to self-describe, hosting their own TDs.
Mechanism for TDs to be hosted in a searchable directory service.
Description of conceptual data organization in a directory.
The HTTP API responses must use appropriate status codes described in this section for success and error responses. The HTTP API MUST use the Problem Details [ RFC7807 ] format to carry error details in HTTP client error (4xx) and server error (5xx) responses. This enables both machines and humans to know the high-level error class and fine-grained details.
The
Problem
Details
error
type
field
is
a
URI
reference
which
could
used
to
map
the
occurred
error
to
WoT-specific
error
class.
There
are
few
open
issues
raising
the
lack
of
WoT-specific
error
types:
wot-discovery#44
,
wot-thing-description#303
,
wot-scripting-api#200
.
For
now,
type
can
be
omitted
which
defaults
to
"about:blank",
and
title
should
be
set
to
HTTP
status
text.
Below is a generic Thing Description for the Directory HTTP API with OAuth2 security. The Thing Description alone should not be considered as the full specification to implement or interact with a directory. Additional details for every interaction are described in human-readable form in the subsequent sections.
The Registration API is a RESTful HTTP API in accordance with the recommendations defined in [ RFC7231 ] and [ REST-IOT ]. The default serialization format for all request and response bodies MUST be JSON, with JSON-LD 1.1 [ JSON-LD11 ] syntax to support extensions and semantic processing. Directories MAY accept additional representations based on request's indicated Content-Type or Content-Encoding, and provide additional representations through server-driven content negotiation.
The Registration API MUST provide create, retrieve, update, delete (CRUD) interfaces based on the following specification:
The
API
MUST
allow
registration
of
a
TD
object
passed
as
request
body.
The
request
SHOULD
contain
application/td+json
Content-Type
header
for
JSON
serialization
of
TD.
The
TD
object
SHOULD
be
validated
syntactically
using
the
Thing
Description
JSON
Schema
[
WoT-Thing-Description
].
A
TD
which
is
identified
with
an
id
attribute
MUST
be
handled
differently
with
one
that
has
no
identifier
(
Anonymous
TD
).
The
create
operations
are
specified
as
createTD
action
in
Directory's
Thing
Description
and
elaborated
below:
PUT
request
at
a
target
location
(HTTP
path)
containing
the
unique
TD
id
.
Upon
successful
processing,
the
server
MUST
respond
with
201
(Created)
status.
Note: If the target location corresponds to an existing TD, the request shall instead proceed as an Update operation and respond the appropriate status code (see Update section).
POST
request.
Upon
successful
processing,
the
server
MUST
respond
with
201
(Created)
status
and
a
Location
header
containing
a
system-generated
identifier
for
the
TD.
The
identifier
SHOULD
be
a
Version
4
UUID
URN
[
RFC4122
].
Error responses:
The
server
should
employ
a
mechanism
to
eliminate
duplication
of
TDs
submitted
with
a
POST
request.
The
spec
need
to
have
recommendations
on
how
to
perform
this.
A
TD
MUST
be
retrieved
from
the
directory
using
an
HTTP
GET
request,
including
the
identifier
of
the
TD
as
part
of
the
path.
A
successful
response
MUST
have
200
(OK)
status,
contain
application/td+json
Content-Type
header,
and
the
requested
TD
in
body.
The
retrieve
operation
is
specified
as
retrieveTD
property
in
Directory's
Thing
Description
.
Error responses:
id
not
found.
The
API
MUST
allow
modifications
to
existing
TDs
as
full
replacement
or
partial
updates.
The
request
SHOULD
contain
application/td+json
Content-Type
header
for
JSON
serialization
of
TD.
The
update
operations
are
described
below:
PUT
request
to
the
location
corresponding
to
the
existing
TD.
The
TD
object
SHOULD
be
validated
syntactically
using
the
Thing
Description
JSON
Schema
[
WoT-Thing-Description
].
Upon
success,
the
server
MUST
respond
with
204
(No
Content)
status.
This
operation
is
specified
as
updateTD
property
in
Directory's
Thing
Description
.
Note:
If
the
target
location
does
not
correspond
to
an
existing
TD,
the
request
shall
instead
proceed
as
a
Create
operation
and
respond
the
appropriate
status
code
(see
Create
section).
In
other
words,
an
HTTP
PUT
request
acts
as
a
create
or
update
operation.
An
HTTP
PATCH
may
be
used
for
an
update-only
operation.
PATCH
request
to
the
location
corresponding
to
the
existing
TD.
The
modified
parts
MUST
conform
to
the
original
TD
structure.
The
input
MAY
include
other
existing
parts
of
the
TD
or
the
whole
TD
object.
When
the
whole
TD
object
is
provided
as
input,
the
operation
acts
as
an
update-only
action.
After
applying
the
modifications,
the
TD
object
SHOULD
be
validated
syntactically
using
the
Thing
Description
JSON
Schema
[
WoT-Thing-Description
].
Upon
success,
the
server
MUST
respond
with
a
204
(No
Content)
status.
This
operation
is
specified
as
updatePartialTD
property
in
Directory's
Thing
Description
.
Error responses:
id
not
found
(for
PATCH
only).
A
TD
MUST
be
removed
from
the
directory
when
an
HTTP
DELETE
request
is
submitted
to
the
location
corresponding
to
the
existing
TD.
A
successful
response
MUST
have
204
(No
Content)
status.
The
retrieve
operation
is
specified
as
deleteTD
property
in
Directory's
Thing
Description
.
Error responses:
id
not
found.
Other administrative functions not having to do with CRUD of individual records, for example, security configuration. Also, administrator roles may expand the capabilities of administrators for management of records (for instance, the ability to delete a record they did not create).
Sub-API to notify clients of events, such as updates to TDs.
Sub-API to search a directory, e.g. issue a query. There are different forms and levels of query possible, for example, syntactic (JSONPath, XPath) vs. semantic (SPARQL), and the more advanced query types may not be supported by all directories. So this API will have further subsections, some of which will be optional. Search also includes a sub-API for managing listing the contents (eg returned by a query) including handling pagination, etc. Note that one special form of query will be able to return everything. Results may be subject to the requestor's authorization.
To discuss further:
Minimum security and privacy requirements for confidentiality, authentication, access control, etc.
This section is non-normative.
Security and privacy are cross-cutting issues that need to be considered in all WoT building blocks and WoT implementations. This chapter summarizes some general issues and guidelines to help preserve the security and privacy of concrete WoT discovery implementations. For a more detailed and complete analysis of security and privacy issues, see the WoT Security and Privacy Guidelines specification [ WOT-SECURITY ].
Special thanks to X, Y, and Z for their contributions to this document.
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.