- 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