W3C home > Mailing lists > Public > public-wot-wg@w3.org > January 2021

[wot-architecture] minutes - 19 November 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Mon, 11 Jan 2021 16:20:04 +0900
Message-ID: <87im84ndnf.wl-ashimura@w3.org>
To: public-wot-wg@w3.org
available at:
  https://www.w3.org/2020/11/19-wot-arch-minutes.html

also as text below.

Thanks a lot for taking the minutes, Michael McCool!

Kazuyuki

---
   [1]W3C

      [1] http://www.w3.org/

                            WoT Architecture

19 Nov 2020

Attendees

   Present
          Kaz_Ashimura, Michael_Lagally, Michael_McCool,
          Daniel_Peintner, Tomoaki_Mizushima

   Regrets

   Chair
          Lagally

   Scribe
          McCool

Contents

     * [2]Topics
         1. [3]minutes of last call
         2. [4]FPWD
         3. [5]Profiles
         4. [6]canonical form and signing
     * [7]Summary of Action Items
     * [8]Summary of Resolutions
     __________________________________________________________

minutes of last call

   <inserted> scribenick: McCool

   <inserted> [9]Nov-12

      [9] https://www.w3.org/2020/11/12-wot-arch-minutes.html

   Lagally: talked about fpwd status
   ... talked about use cases
   ... for VR-AR and agriculture
   ... then looked into requirements, e.g. linking

   <mlagally> [10]Transition request

     [10] https://github.com/w3c/transitions/issues/282#issuecomment-723282838

   Lagally: fpwd review included feedback that use cases and
   requirements should probably be in a separate informative
   document

   <mlagally> [11]Issue 565 on the comment within the Transition
   request

     [11] https://github.com/w3c/wot-architecture/issues/565

   Lagally: any concerns about these minutes?
   ... SV_MEETING_CHAIR should be updated

   Kaz: fixed

   Lagally: any objections to approve?
   ... no, approved

FPWD

   Lagally: is there anything we have to do?

   Kaz: files have been copied to a subdirectory

   McCool: so PRs against the root index.html won't change the
   published version, right?

   Kaz: correct
   ... actually, did not yet do this for profiles, but did do it
   for architecture
   ... see wot-architecture/publication/ver11/1-fpwd

   Lagally: what is orig.html?

   Kaz: original version
   ... index.html is the static generated version

   <kaz> [12]Kaz's comment

     [12] https://lists.w3.org/Archives/Member/member-wot-wg/2020Nov/0007.html

   Kaz: on previous topic, still need to fix some issues...
   ... in particular we should think about how to name ids

   Lagally: did you solve this?

   <kaz> 

   <kaz> > > * duplicate ID "lifecycle-1" used for both the
   figures of "Simple system Lifecycle" (Figure 20) and "Device
   Lifecycle" (Figure 22)

   <kaz> > > => use "fig-simple-system-lifecycle" as the id for
   Figure 20 and "fig-device-lifecycle" as the id for Figure 22 to
   avoid dupulicated IDs

   <kaz> > > => probably we should rethink about the policy for
   the IDs of the figures

   <kaz> ]]

   Kaz: for the publication version, yes, but need to update
   master version

   Lagally: why don't we just use whatever you did
   ... having duplicate ids is just an editorial issue, so please
   just create a PR

   <kaz> ACTION: kaz to create a Pullrequest for the editorial
   changes for the publication to update the master index.html

Profiles

canonical form and signing

   <inserted> [13]wot-profile PR 51

     [13] https://github.com/w3c/wot-profile/pull/51

   McCool: recap, ld-proofs use jws, and jws may define
   canonicalization
   ... json-ld has a few more issues but affect only a few use
   cases

   <Zakim> dape, you wanted to canonical form vs default values

   Daniel: default values may also cause a problem

   Lagally: true, we need to define if default values are always
   given or always not given

   seb: what is definitely missing in TD spec is how to process
   TDs that are missing some mandatory terms that need to be added
   by the processor
   ... is a missing algorithm
   ... there is an issue in the td that repo explains this
   ... for example, readOnly and writeOnly, which are checked by
   op values
   ... need to define readOnly and/or writeOnly FIRST, then can do
   op
   ... there needs to be an order of default assignment
   ... possible to generate the wrong result if follow what TD
   spec says about missing op value

   McCool: we probably need to add an algorithm for canonical
   ... it makes it much easier to implement things like
   directories
   ... if we don't canonicalize, then it forces things like
   databases to store things as strings
   ... which can break queries, etc.
   ... we need to look at the jws spec to see what its
   requirements
   ... so even if the jws includes intrinsic canonicalization, we
   probably need to clean up a few things
   ... I can think of default values and any place where we
   represent sets using arrays
   ... for the latter I would suggest not allowing reordering of
   any array, even if it is technically a set

   <kaz> [14]JSON Web Signature (RFC7515)

     [14] https://tools.ietf.org/html/rfc7515

   Kaz: vc data model has a specific section about jws

   <kaz> [15]Verifiable Credentials Data Model 1.0 REC

     [15] https://www.w3.org/TR/vc-data-model/

   McCool: suggest we get someone to review

   Lagally: we could go further, say we are adopting jws
   ... and then add some additional constraints

   McCool: my concern is just that we should avoid adding
   redundant assertions

   Lagally: let's look at the vc data model reference...

   McCool: looks like it explicitly says that signature can be
   against either serialization or against data model

   Lagally: I'm sure others have come across this issue already
   ... let's do some research and then pick something that is
   widely accepted

   McCool: agree

   Lagally: looks like there are some IETF drafts for dealing with
   this
   ... see JCS
   ... RFC8785

   <mlagally> [16]https://tools.ietf.org/html/rfc8785

     [16] https://tools.ietf.org/html/rfc8785

   McCool: looks like a good place to start; need to consider
   errata
   ... I see there is an assertion about not changing the order of
   arrays, which is good
   ... but we need to make sure this is reinforced in the TD spec
   ... eg, forms, ops, etc. are in arrays, technically they can be
   reordered without changing the meaning of the TD
   ... but such reordering would break signatured

   Lagally: well, JCS seems like a good place to start anyway

   McCool: agree

   Lagally: any other business?

   <kaz> (none)

   <kaz> [adjourned]

Summary of Action Items

   [NEW] ACTION: kaz to create a Pullrequest for the editorial
   changes for the publication to update the master index.html

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [17]scribe.perl version
    1.152 ([18]CVS log)
    $Date: 2020/12/17 14:36:33 $

     [17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [18] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 11 January 2021 07:20:08 UTC

This archive was generated by hypermail 2.4.0 : Monday, 11 January 2021 07:20:09 UTC