<manu> scribenick: mike-lodder
<stonematt> https://lists.w3.org/Archives/Public/public-vc-wg/2019Jan/0030.html
stonematt: topic is agenda review
stonematt: f2f sign up
<stonematt> https://docs.google.com/spreadsheets/d/1G1ygbZMI5nJB94ROuX-Vtic4FgbeYl-S58E_DoXa7-w/edit#gid=913829325
stonematt: we sent a link to this
sign up last week for those who intend to attend
Barcelona
... need to know who's coming for logistical reasons
... any questions about F2F
<Zakim> manu, you wanted to discuss comments
manu: adam lake from Digital
Bazaar is looking at hotel accommodations
... those that are within walking distance to RWoT
... buying lunch and snacks only, no breakfast
<kaz> f2f page
stonematt: please put hotel
recommendations in the document
... and for transportation
... moving on to unassigned issues
<stonematt> https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is%3Aissue+is%3Aopen+no%3Aassignee
stonematt: need to know if any of
these are CR blockers
... 383 contains no CR blockers
... manu to verify
manu: 383 is only editorial
<kaz> issue 383
<stonematt> https://github.com/w3c/vc-data-model/issues/381
manu: I'll take 383
... 381 is editorial only
<stonematt> https://github.com/w3c/vc-data-model/issues/380
manu: 380 is problematic, CR
blocker
... I'll take that one
<stonematt> https://github.com/w3c/vc-data-model/issues/379
manu: 379 is editorial, assigned to Amy
<stonematt> https://github.com/w3c/vc-data-model/issues/371
manu: 371 needs to be fixed but
not a CR blocker
... 371 is a CR blocker
<stonematt> https://github.com/w3c/vc-data-model/issues/363
manu: 363 is editorial
... spec text change only
... assign to myself
<stonematt> https://github.com/w3c/vc-data-model/issues/362
manu: 362 editorial only assigned to myself
<stonematt> https://github.com/w3c/vc-data-model/blob/gh-pages/VCDMExplainer.md
stonematt: where are we on the explainer? what's left?
ken: ZKP angle, brent and I have finished
jwt: is there an example for ZKPs and JWTs?
stonematt: manu can you provide guidelines for how much content is needed?
manu: I don't expect we need a
lot of examples
... since we have a ZKP one, lets add a JWT one
ken: agree we should have discussion on feedback and need resolution on small issues
manu: these affect the examples in the explainer
<stonematt> ACTION: Oliver_Terbu to add JWT example to explainer
stonematt: oliver will you submit the JWT example
ken: they also affect the
examples in the explainer
... but not CR blockers
stonematt: agreed, just need to
reduce duplication in multiple places
... need a reasonable due date, can they be completed by
Thursday, or end of week?
brent: I think the only missing
element is the JWT example
... if oliver can get it done, then end of week is
reasonable
manu: features at risk section is not filled out yet
<Oliver_Terbu> oliver will provide it either today or tomorrow
manu: someone needs to shepherd the process
stonematt: is that required before we go to Tag review?
<Zakim> manu, you wanted to can volunteer to do features at risk.
brent: ken and I did an editorial pass, clarified the data model, and fixed a lot of old texts, I'll take an editorial pass but not the at risk section
manu: I will take the at risk
section
... need to understand what implementation of features
means
... we know which features are at risk and which ones are
not
ken: there is one section "Selective Disclosure" that hasn't been reviewed yet either
manu: probably another about JSON, JSON-LD
ken: headers are there but discusses JWT
manu: trying to remember other
topics that were controversial
... probably need to add some more things
... like authorization
... anything debated (frameworks) need to be covered
<Oliver_Terbu> q
Oliver_Terbu: there is some confusion around can implement or will implement, needs clarity
<brent> +1
stonematt: we will discuss
next
... do we still think Thursday is a reasonable deadline?
manu: if brent and ken feel comfortable writing "this was a tricky design goal" then that might be enough
<brent> +1
ken: brent and I can take the
"Selective Disclosure" portion
... I don't know what to write about other sections like
"authorization"
manu: I need to add something to
the explainer anyway
... I'll take that assignment
<Ned> [/help]
stonematt: can we recount the missing topics
<stonematt> recounting "tricky design decisions" that are missing: Terms of Use and Authorization
stonematt: authorization, terms
of use
... this document is getting big
<stonematt> https://docs.google.com/spreadsheets/d/1SzfAUA0J72-1BORHJEmY4cdZrQ6vmKy4oq_24r_NwB4/edit#gid=0
stonematt: manu sent a list of features might be implemented,
manu: every feature needs to be
implemented by at least two consumers
... a number of features that we need to know if they intend to
implement
... some features are trivial to implement
... and if you don't implement it, its probably due to
philosophical differences
stonematt: if anyone is missing from the list, let us know and we'll reach out to them and get commitments
manu: must take a JSON document
and process it
... no signatures required to pass tests
... need volunteers to write tests, these tests are simple
JoeAndrieu: manu, are you suggesting that tests are required?
manu: checking of linked data proofs is not required
JoeAndrieu: I didn't see it in the charter, so I'm confused where this is coming from
<stonematt> how do we show "tamper evident"
JoeAndrieu: need to define how to
determine if its valid
... is it outside conformance to determine if the crypto suite
is valid
<manu> https://www.w3.org/2017/vc/charter.html
<manu> https://www.w3.org/2017/vc/charter.html#deliverables
JoeAndrieu: specifying the
relationship between the proof and document
... not the crypto suites
stonematt: need to show document tamper evidence
<Zakim> stonematt, you wanted to say how to we show "tamper evident"
<manu> https://www.w3.org/2017/vc/charter.html#deliverables
manu: JoeAndrieu you are correct, it says we can recommend
<JoeAndrieu> present_
manu: we can invent new crypto
for this but others will not like it
... not an official requirement to pass crypto suites
... test suite can have optional tests
... not required for conformance
... JWT has IETF specs that we can point to
... but can't do it for ZKPs
... or the LD-proofs
JoeAndrieu: we can't test without specifying which crypto suites are used
ken: three items
... we will rust code that Evernym builds on top of Sovrin's
implementation, is that two different implementations
manu: no because you are
collaborating
... can't be too close
ken: 2nd item, what form does the input come in for the test
manu: JSON-LD document, processes it and puts out the proof attached
ken: last item, terms of use, we won't be implementing it
manu: they become features at risk if we don't have two implementers
ken: I will connect with you (manu) about that
<Zakim> stonematt, you wanted to say do we care about market value of the DM w/out crypto details?
stonematt: I don't think we had
clarity about crypto suites in the tests
... if we had a decision can you please put it down
manu: we didn't have a decision
on that
... Joe would like to see more specific tests
... could add some that check RSA2048 and Ed25519
... but is anyone else going to implement that
... can't make it a requirement of the conformance suite
kaz: pleae note that test suite is useful but
it's a separate delivelable from the spec itself, ans it's not required for spec transition itself
... so we should be clear about the requirements for our test suite (as an additional deliverable)
... from the spec transition viewpoint, what is more important is generating a list of assertions which covers all the features from the spec
<Zakim> manu, you wanted to note, yes, additional requirement, but I think we're committed to something at this point.
manu: its optional, but group has
committed to have a test suite
... how far do we go to check the crypto
kaz: we can clarify our own requirements for this to work effectively
manu: we can put in tests that
check in detail RSA2048 and Ed25519 but they won't be
official
... then discuss what else needs to go in there
<stonematt> thanks all!