<stonematt> Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018Dec/0016.html

<stonematt> Scribe: Yancy

<stonematt> scribenick: Yancy

Introduction

<weiler> weiler: I work at MIT on the W3C helping with security and privacy strategy. I met many of you at recent TPACs and at the workshop

<weiler> ... at Microsoft last week. Just dropping by.

<manu> rhiaro: Hi Amy Guy, will be working with Digital Bazaar on some W3C spec work.

Unassigned Issues

stone: next topic

<stonematt> https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is%3Aopen+is%3Aissue+no%3Aassignee+-label%3Adefer

stone: 312 cr blocker?

manu: no that's no a cr blocker
... can close with no changes
... how do we know if next one is a cr blocker
... I can take tat one as well
... 317 is the only one that's a blocker

<manu> https://github.com/w3c/vc-data-model/issues/336

manu: also wanted to point out that other one is blocker 336
... job stuff in the spec but there are interop issues that need to be cleanedup. it's an iteration on the job stuff

stone: that work is progressing. do you want to introduce an agenda item

manu: oliver to respond

stone: next topic

Document Conformance for Data Models

stone: introduced by dan b on 317

<stonematt> https://github.com/w3c/vc-data-model/issues/317

burn: there have been a number of topics such as valid vs verify. ted has brought up concerns many times that this is data and syntax being discussed and not data model
... where to draw the line of syntax vs data model
... to complete candidate recommendation we need demonstrations of implementations
... have worked on other specs
... jsonld is a special case and feel free to look at those in the meantime

<Zakim> manu, you wanted to note that I added a CR Blocker

burn: brief summary were after document conformance
... it is not appropriate for us to put requirements on what an issuer must do and what a verifier or holder must do to receive a document
... very important we get this fixed
... once we get this fixed we shouldn't have problems holding to the scope
... one way to think of this is that it can be helpful to think of this as this is a property of
... issuer, holder or verifier
... if so this is probably syntax on the model
... anything else is informative
... we just need to be careful that it's not normative
... for com-formative they are true no matter what
... some examples in 317
... not correct for the spec. for example, the age property is a little complex but it's still static
... not appropriate the verifier must make sure the expiration hasn't gone passed the current date and time
... dereferencing is in the category of issuer of verifier and not in scope for our specification
... usage guidance is not normative

<manu> +1 -- don't know why we didn't think of this like a year ago :)

<TallTed> +1000000 This is exactly the direction in which I've been trying to push.

stone: the key verb for us is verify or verifiable

<manu> TallTed, see - we listen to you, man. :)

<manu> (eventually) :P

<manu> also, +1 this is really going to help the editorial process.

burn: how to draw the line. even when you look at the implementation report and statements, some of the statements get close to behavior
... no way we can require producer or consumer of data

ted: exactly what he hoped would be done
... all actions are protocol

burn: can't go beyond charter
... we must stay away from non charter for now

stone: how are we going to use the existing testsuit?
... we have implementors that are building sofware, agents etc
... and api/protocol

<TallTed> WG-Note is a great place for things like Implementation Tests that are more about Protocol than Model

stone: when it comes to the work that we've done, that work can go and reference discussions we've had but it doesn't rep the data model

burn: does not mean throw away. a lot of great work has been done but we need to make sure or spec is clean

<kaz> yet another example of WoT Thing Description implementation report

kaz: another exmaple
... very similar work to verifier model
... they are also implementing data model features (and serialization of that data model based on JSON-LD), so could be yet another example

<Zakim> burn, you wanted to talk about JSON-LD

burn: said would come back to jsonld as an example
... found interesting quirk in jsonld spec
... two parts grammar and transformation
... jsonld documents conforms to grammar
... the two specs both reference the same implementation report
... why he put this as not applicable

<TallTed> +1 our requirements are different than JSON-LD had

burn: it is only the requirements on the document that matter
... which is why NA was used for jsonld

stone: discussions in redmond about what's conformant in the document
... going back to grammar - subject verb agreement

burn: wanted to get this in this call because of break coming up
... and to think about this in these terms
... matts example is a really good one about the proof section
... really good conversation about proof section
... if a relationship can be defined that is a static relationship then it could be ok
... must be really careful about the relationships between parts of the document
... one attribute is greater than the other

<Zakim> manu, you wanted to ask for reviews (with PRs!) over the break, we only have ZKPs as the last big outstanding feature (on me), we're running out of PRs (which is a good sign).

burn: always need to come back to what properties are static without relation to producer or consumer

manu: all of that is great stuff
... hopefully people will have spare time during the holiday
... to review the document
... fantastic job doing PRs so far

<dlongley> so perhaps for JWTs... "if you have the property `sub` at the top level of the JWT, it is equivalent to having the property `id` in `vc.credentialSubject`" ... and then informatively mention that the expectation is that signature verifiers will do this transformation automatically (this is if we decide we need these transformations)

manu: able to merge in a lot more of the PRs because they are on point
... only one spec is having issue which is ZKP
... does not know if brent is planning on updating and manu needs input

<burn> dlongley, 'equivalent' is tricky. Try to stick with MUST/MAY/SHOULD if possible

manu: mostly document cleanup based on what dan and matt have been talking about today
... merged in 15-20 PRs which is great
... no large design changes
... thinks the only request is to please review the spec
... if we get those two addressed that's all the outstanding PRs we have so far

burn: now done with topic

brent: is planning on making changes to that PR
... have a good sense and getting together with manu and dave
... confident we will have the PR ready to go

ken: want to agree with what brent had to say and are close to finishing

burn: thanks for all the work

<dlongley> +1

ken: thanks to manu and dave l

<oliver_terbu> also thanks to manu and dave

stone: new topic

burn: to submit one PR
... we need people to review and submit PRs

PR review

<stonematt> https://github.com/w3c/vc-data-model/pulls

stone: PR reviews is next on the list

<Zakim> manu, you wanted to ask if there is anything that folks think we're missing? Anything big?

stone: any of these manu wants to run us through?

manu: only 5 so we can go through on the call

<manu> https://github.com/w3c/vc-data-model/pull/229

manu: PR 229 dropping link
... spec does not deal with authorization
... need to think long and hard about doing delegation

<manu> https://github.com/w3c/vc-data-model/pull/265

manu: someone object or else it's getting closed
... dave and I have some action items but no concerns for 265

<manu> https://github.com/w3c/vc-data-model/pull/283

manu: remove delegation to be merged after conflicts resolved

<manu> https://github.com/w3c/vc-data-model/pull/313

manu: next one is 313
... life cycle example. is this PR ready to go?

stone: manu requested change to format and readability of source, then ready

manu: will try to fix up changes and pull that in

<manu> https://github.com/w3c/vc-data-model/pull/322

manu: has to do with jwt stuff
... needs to two things added. need to figure out what transform rules are.

<oliver_terbu> base64

<oliver_terbu> yes, i will create these two PRs

<manu> +1, thx oliver_terbu

<JoeAndrieu> https://github.com/w3c/vc-data-model/pull/298

<Zakim> JoeAndrieu, you wanted to talk about https://github.com/w3c/vc-data-model/pull/337

joe: not sure if you realize but 337 is why 298 was closed
... but it didn't really

manu: missed that but thank you. open 298 again?

burn: rewriting 6.2 section is his PR
... we will need to discuss if there are existing PRs that may be in part correct that we may want to merge understanding there isn't consensus

manu: should never have closed 298

joe: will pull in upstream edits and push

zakim: should we reuse issue?

manu: did add one new issue but you can use that one

davidc: 337 said it helps to resolve. don't say the he said it did resolve

manu: davidc used language that triggered github to close
... the robots have turned against us

stone: thanks for a good call

<burn> Next meeting 3 weeks from today

<kaz> Jan 8

<kaz> [adjourned]