Meeting minutes
Agenda
<kaz> agenda for today
Sebastian: we will start with profile discussion
Architecture Planning
<McCool> wot PR 1096 - Architecture Planning
McCool: we have to discuss about arch spec being informative or normative
McCool: we have to decide
what to do with the current normative content
… also we have to decide what the purpose
is
… I have listed what it does
… half of the current assertions are about
security
McCool: do we have assertions for the whole WoT?
McCool: maybe those assertions are actually requirements so we can restructure like that
Sebastian: my experience is that arch document is not implemented by developers, so the restrictions do not apply to them, since they are not aware
Sebastian: REC implies W3C process, overhead in general
McCool: we have lots of deliverables, each imply work. We can consolidate but not lose information
wot-charter-drafts issue 15 - Arch: Architecture Brainstorming
wot-charter-drafts PR 85 - Add Architecture as an informative deliverable
wot-charter-drafts PR 82 - Add Architecture as a normative deliverable
Ege: people are showing to management to explain wot. developers do not read the normative part
Kaz: We said it would be a normative deliverable in the proposed WoT WG Charter. We should work on the document refactoring for the whole WoT specs, and as a result, if there are only informative portions within the WoT Architecture spec, that would automatically become an informative spec.
McCool: we can work towards informative and do the transition when it is doable
McCool: the document should not go away, the introduction to wot is useful
https://
Luca: I support non normative
https://
Ege: we have also introductory part in the web page, which is the most popular page after landing
McCool: a formal looking explainer is nicer than a webpage but I will add to discussion
McCool: we have requirements that sometimes apply to multiple documents so we need to duplicate that maybe
McCool: should we move application domains to use cases?
Ege: arch application cases show an agreement. use cases document are individual submissions
Kaz: we had discussions in that direction about restructuring use cases. So the details to be discussed collaboratively with the Use Cases TF.
McCool: let's look at the assertions and normative content
McCool: we cannot constrain
brownfield systems, we only describe them
… so all the normative assertions can go to a
profile
McCool: we also have discussions on TDDs having profiles
McCool: i think profiles is the best direction
Ege: I think that
security assertions should be best practices
… moving to a profile would have problems with
protocol dependency
McCool: I think that security should be normative
McCool: we can have baseline security and add protocol specific assertion to profiles with those protocols
Kaz: We should have discussion about which security features are really needed first, and then think about which spec to have that.
<Mizushima> +1 kaz
Kaz: The name of "WoT Profile" is still a bit odd to me but it does describe possible and natural implementation patterns for WoT-based IoT services. So it's possible to transfer the security portions to WoT Profile. However, it's not that "WoT Profile is the default place for the transfer." and we should think about which spec to have the feature.
Luca: profiles are
important if you want to interoperate with devices with different
physical constraints
… we are lacking there completely. Security is
important since they require different resources
Luca: about image, we can put a section about expectations of a system that should be secure
Luca: you are implementing wot, so you are signing up for the safety of the user
McCool: there are optional features for PII sensitive points
Ege: we can understand some security for TD instances
McCool: not always. some assertion from TD can go into other specs
Sebastian: we have to discuss who will lead the TF
Sebastian: mccool did it interim
McCool: I think the motivation is to reduce the document size
McCool: I think we should find somebody but I can do it until then
McCool: same for security
McCool: I can chair and do another TF
Sebastian: Jiye is not active
at the moment
… I am looking for another person
McCool: we need someone for reviewing the documents, an expert. And another person to moderate
Kaz: we can send a call for participation
McCool: we have to have a discussion on finding TF leads during the Chairs calls
Security Planning
<kaz> wot PR 1097 - Security Planning
McCool: signing JSON-LD is
complicated
… it can blow up in some cases
McCool: we would to need to decide whether TDs can be modified by directories or not
McCool: we have the topic about fixed prefixes for pure JSON processors
wot-thing-description Issue 1774 - Not changing prefix of ontologies we suggest
McCool: we have to discuss onboarding as well
Ege: I can share some
work on security extensions and I have put an issue above about
prefixes
… I think onboarding needs its own deliverable
since it is not just about key exchange or security. It should be
the lifecycle
Luca: I think it is a
usage of wot, should not be a normative spec or constrain wot
applications
… regarding JSON-LD, we can do it in profile and be
strict
McCool: JSON-LD signing is for arbitrary graphs
Luca: we have tried to
JSON-LD for everything like extensions
… it is great for non functional extensions, so it
would be bad to restrict it
Luca: degraded consumption would be an interesting topic
Kaz: this is a bigger discussion for today, so would suggest we talk with the JSON-LD/VC/DID guys during TPAC since they're also working on this issue.
Sebastian: we can talk about onboarding with OPC UA WoT Connectivity WG since they need this too
<mjk> scribenick mjk
profiles
<kaz> -> slides TBD @@@
Ben: presenting slides on profiles
Ben: option 1 proposal
is to handle protocol bindings defaults as required in a
profile
… option 2 proposal is to continue to define
protocol bindings for profile separately from the standalone
protocol bindings
McCool: how much testing work is needed?
Ben: there are not enough implementations yet
McCool: there may not be a lot of effort lost in reorganizing things now
McCool: are profiles only constraints on TDs or are there also constraints on behavior?
Ben: option 2 would mean publishing profiles 1.0
Ben: with option 1 we would constrain supported mechanisms and be more specific about the types of assertions that can be in the profile
McCool: should security assertions be part of a profile?
Ben: prefer that security assertions be in a security best practices document and leave profile assertions to be more cleanly testable
<McCool> (ben's feedback: would rather assertions on implementations should be in a guideline document, not in profile, make testing difficult)
Kaz: this should be part of the overall restructuring project so we can see the whole structure across all documents
Ben: agree
Sebastian: assume that
profiles will include a basic mechanism and generic definition, and
a set of specific profile documents that conform to the generic
description
… for example a manufacturing domain profile that
works more or less like a protocol binding document
Ben: we originally thought of profiles as a protocol constraint like a sub-protocol
Sebastian: do we have enough members interested to make profiles happen?
Ben: last 6 months has
been spent implementing TD 1.0 with particular profiles but not
completely attached to the profile approach
… could use another mechanism like
subprotocols
Ege: leaning more
toward option 1 to provide a clearly defined mechanism
… with subprotocols also
… subprotocols may not be W3C work
Luca: would like to see
the concept of profiles extended beyond protocol usage
… the use as a mixin solves a lot of
problems
… we could reconsider in next TD how we handle
protocol selection
… regarding SSE, have an implementation that
reduces the risk
… would keep profiles because it solves a lot of
problems
Sebastian: can you (luca) be involved in the profile activity?
Luca: yes
Mizushima: agree with the
direction but profile is different from a binding
… we should discuss what a profile is
Ben: agree, profile is not the same as a binding but more of a constraint
<luca_barbato> test-consumer for SSE
Ben: a profile is a constraint to guarantee interoperability
Kaz: suggest we
continue this discussion as part of the larger document refactoring
issue
… we should send out a call for participation for
profies
Sebastian: should profiles be rec track or moved to a note?
<benfrancis> For the notes: Protocol binding is just one aspect of a Thing that a profile can constrain. Others are payload binding, discovery mechanisms, security mechanisms, semantic ontologies, link relation types etc.
<kaz> (Ben's clarification above to be moved right after "more of a constraint")@@@
Sebastian: we need to think about the best way to proceed
new working mode for the next charter
Sebastian: we have too many
calls
… would like to optimize the calendar and reduce
the load of calls
… also need to consider the time zone
considerations, particularly for the TD call and participants in
Asia
… maybe we shouldn't work on multiple deliverables
in parallel
… reduce the frequency of note workstreams to 2
week interval
… use more async process and use meetings to report
and summarize
… prepare the agenda for calls one day in
advance
… suggest a goal of 4 calls per week
maximum
McCool: does 4 calls per week include the main call, and can we have the main call every 2 weeks?
Sebastian: sometimes we may need more frequent calls during preparation for publication
McCool: we could have shorter calls
Kaz: would personally welcome fewer calls, but simply reducing the load should include a discussion of how to make each call more productive
Sebastian: removing PR review from the calls could help
Kaz: it's difficult for all participants to follow and understand the points of the PR discussions
Sebastian: we could share the detailed agenda and ask for discussion before the call
Kaz: that may not work for all participants, but we could try for a month or 2
Ege: agree with the
overall idea and async process, the TF moderator can make the
decision about whether more calls are needed
… would like the main call to have more report out
and sync between TFs
… maybe alternate TF reports every 2
weeks
Ben: supports fewer
calls and more async collaboration
… we do need to work on some items in
parallel
… wonder if minutes approval can be done outside
the meeting
<McCool> (time check)
Kaz: OK with this
direction if everybody is OK, but we need some prototyping
… TF moderators will need to coordinate more to
clarify what is done and what is needed
… suggest a Also TF moderator call
Sebastian: agree and we should prototype this also
Mizushima: agree with the
direction of the proposal. We should separate WG and IG
meetings.
… I'm confused
Kaz: we should further clarify the difference between WG and IG responsibilities
Sebastian: let's have further discussion on this proposal
Kaz: agree
Sebastian: this concludes the week's meeting, we can discuss among the chairs and propose next steps
Sebastian: thank you and adjourned for today
<kaz> [adjourned]