- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 11 Jan 2021 16:20:04 +0900
- 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