<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
<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]