WoT Architecture

19 Nov 2020


Kaz_Ashimura, Michael_Lagally, Michael_McCool, Daniel_Peintner, Tomoaki_Mizushima


minutes of last call

<inserted> scribenick: McCool

<inserted> Nov-12

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

<mlagally> Transition request

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

<mlagally> Issue 565 on the comment within the Transition request

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

Kaz: fixed

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


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> Kaz's comment

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


canonical form and signing

<inserted> wot-profile PR 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> JSON Web Signature (RFC7515)

Kaz: vc data model has a specific section about jws

<kaz> Verifiable Credentials Data Model 1.0 REC

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> 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 scribe.perl version 1.152 (CVS log)
$Date: 2020/12/17 14:36:33 $