<rhiaro> scribe: rhiaro

<burn> Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2019Jun/0011.html

Describe plan for the call

burn: same plan, go through PRs and issuesa nd move on to test suite, and anything else that is implementation related
... anything else?

PR announcements

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

manu: we have a couple of PRs piling up, will get to them this week, will be done by the end of the weekend at the latest
... many of these are old

<burn> https://github.com/w3c/vc-data-model/pull/641

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

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

manu: oliver, based on what I heard are you concerned about getting this iat nbnf and misleading statements in? I don't see any issue, we should be able to pull those in. Do you have background on 668 or 670 that you want to cover?

oliver: Is tallted on the call?
... as far as I know the nbfs PR ?? looks like number ..

TallTed: I think I'm good with this, I had a rephrasing on 670 of issue 669, about the ait must be set for digital signatures. My wording is because used is an overused word, set is right for what we're talkinga bout

oliver: I didn't have a chance to update the PR, I spoke to some of our uport guys to do it on behalf of me, I'm fine with the new language
... also fine to provide an additional PR later this week if necessary

TallTed: I can make the suggestion as a PR against your fork

oliver: that would be great thanks

manu: I'm not hearing any big issues> once that's in I can merge, and Ted yours would be a new PR on top of that
... I'm not hearing any issues with those PRs
... oliver, if we make those updates you're happy with the state of the jwt section?

oliver: yes, I'm fine with renaming iat into nbf, ?? should reflect that change, this is what we agreed last week

manu: dmitri is that an update you had scheduled for the test suite?

dmitriz: I believe oliver made that update in parallel, just waiting on the spec update, should be in there I think

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

manu: looking at 663, it's a fairly benign change, any concerns from you?

TallTed: no, if it goes in I'm good

manu: good, it'll go in

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

manu: next up is 664
... which is the nbf not iat one. Is this also needs to go in along with olivers updates? or is this .. this feels like it might stomp on oliver's pr

TallTed: it might even be the same

manu: I'll merge oliver's PR because it has more changes in it, and then I'll check line for line whether your PR is reflected in his PR

TallTed: my PR is two three character changes

manu: My expectation is oliver's pr includes that

dlongley: oliver's covers everything that Ted's does

manu: I'm going to close 664

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

manu: next 665
... by brent
... looks like thumbs up from longley and dmitri. Anyone else had a chance to review?
... this is a clarification not a substantive change
... looks good to me
... but we need another reviewer not from digital bazaar
... thank you ken

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

manu: next up 666
... by markus
... seems benign
... it's a typo, we'll merge that (what's the worst that could happen)

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

manu: 671 is DavidC

TallTed: it's covered by 670

manu: but that one got closed
... why is this closed

TallTed: not closed yet

manu: 670 is changes requrested. We'll close 671 since it's included

TallTed: that's what I would do

manu: that's all the PRs. Nothing controversial there. We're trying to get to PR (Proposed Rec) as quickly as possible. Any outstanding PRs (pull requests) that people feel they m ust get in before I make a final Proposed Rec version of the spec?

oliver: what about the test suite PRs? There are a bunch of tests for covering jwts that might be important to get them in before PR

<dmitriz> https://w3c.github.io/vc-test-suite/implementations/#conformance-testing-results

dmitriz: we're gonna talk about it in the call, they should all be in and we have the updated conformance results over here ^
... so that includes uport, digital bazaar, sovrin, evernym, danube tech and credly
... there's still a work in progress in dividing the implementationr eports into intentially not implemented vs otherwise but this should be the latest snapshot

manu: have you had a chance to chat with andrew jones, dmitriz, on the work he's done to split up optional vs not optional tests?

dmitriz: yes
... I have, this is one step past that in the sense that not only do we have required vs optional we also have presentation vs credentials, we have a matrix
... that's still being updated
... we're coordinating

burn: oliver if you're going to be on later, the report shows a large number are not successful for you which I think yo uthink should be. We shoulld cover that later

dmitriz: I suspect that's an artefact of the test setup

manu: we're at the end of CR, the expectation is the spec is locked down. We'll not be making any changes, that's the frame of mind you should be in. There may be editorial changes if we find that there is a normative change we need to make we'll have to go back to CR (we don't have time)
... it's super important that we make sure there's nothing else anybody wants in this revision
... the other thing that's imporant is to make sure, as oliver mentioned, that every test you want to see passing is passing in the test suite. Once we see that, the report is that, and we see two checkboxes for every feature we want, that is the signal typically that it's safe to go to proposed rec
... because that means we can keep those features, rip out the feature at risk stuff which don't have enough implementations. That's what we're doing when we go into proposed rec it's sent to the membership and they get one last go at the spec to see if it's appropriate, they have the option to raise formal objections to transition to rEC, and editorial changes, based on the feedback we get we have to make a decision about whether the spec is done.
... Going back to work on it would require rechartering. Or it's just a bunch of editorial things we missed during review
... all that to say the gating factor right now I think is making sure that the implementation report is exactly where we want it to be and I think the only thing we're really waiting on is the jwt stuff, we have to make sure there are two conforming implementatoins for the jwt stuff. My understanding is that oliver and markus have implementations. We have to see green checkmarks across them. Once we have that we're ready to go to PR
... and in preparation for that I'm going to make a PR-ready spec
... that doesn't mean we're going into PR when that's ready, just thatw e're locking it down

burn: time to select our scribe

<rhiaro> scribenick: stonematt

ken: some internationalization exams covered?

manu: status is complex, we know what to write in spec.
... no i18n tests in spec. examples are non-normative. will update to reflect where we are.
... discussion has triggered an update to the spec in another WG

ken: thank you. how about #641?

manu: will resolve/fix

ken: 2nd item. test results don't reflect what I thought my implementation for ZKP

dmitriz: will look into it.

ken: file issue?

burn: yes
... we about to call the spec "done", so if there's an issue or potential issue in test suite. file it

dmitriz: should we have i18n test?

manu: we could have one in the example context. requires some details to take offline. a bit hesitant - requires everyone to run the test suite again, if we add a new test

<Zakim> burn, you wanted to explain about IR after PR

manu: we can add it post rec - we can add tests during maintenance mode

burn: regarding implementation reports: if you know someone else who may not be able to get the implementation done, they can still be submitted after PR. They will not be listed in the initial set when we go to PR

<dmitriz> ken: I see the ZKP test results in the report's JSON, so I suspect the issue is in the HTML generation.

manu: will confirm that we have the latest and greatest from each. and confirm that the report reflects the results of each test
... did you have time scheduled this week

dmitriz: yes and have meetings scheduled. will make another pass to reconcile spec to test suite one last time

<rhiaro> scribe: rhiaro

stonematt: did we set a date when implementations need to be in? If we know people who are working on one? Can we give them a real date rather than do it as fast as possible?

<scribe> scribe: stonematt

stonematt: on the implementation reports, whats the deadline?

manu: July 5

Issue lightning round: close the issues we can

<burn> https://github.com/w3c/vc-test-suite/issues

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

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

manu: looks good right now
... burn is planning to close some 7day close issues
... bit open issue is DavidC type discussion. will have a meeting this week offline w/ manu and stonematt
... any other issues?

Oliver: do we need to get PRs in for the implementation guide also?

manu: yes

Oliver: will review and submit next week

manu: you can go ahead and put in PRs on the implementation guide b/c it's a WG Note

Oliver: also need to update my report

manu: chat w/ marcus to verify that both implementation cover the same tests, so we have at least 2 tests for each feature

burn: wil start coving implementation guide in future agendas

DavidC: also have a colleague doing a JWT implementation.

Test Suite Issues and Discussion

<burn> https://github.com/w3c/vc-test-suite/issues

ken: Evernym's implementation showed passing in JWT section also

burn: dmitriz please review verify readiness of TS . it will become the blocking factor in PR soon

<burn> https://github.com/w3c/vc-test-suite/issues/59

dmitriz: assign to self to fix html generation

<dmitriz> https://github.com/w3c/vc-test-suite/issues/45

dmitriz: issue 45 test suite. error in report generation. fixed PR 57
... issue 30, categorization of tests, assign do dmitriz

<dmitriz> https://github.com/w3c/vc-test-suite/issues/30

<dmitriz> https://github.com/w3c/vc-test-suite/issues/28

dmitriz: somewhat mysterious report generation failure. will coordinate w/ ken and bzundel
... need help debugging

issue 23

<dmitriz> https://github.com/w3c/vc-test-suite/issues/23

dmitriz: missing copyright - will be adding that today

<dmitriz> https://github.com/w3c/vc-test-suite/issues/22

issue 22

dmitriz: tests change to RFC3339. address this week by dmitriz

<dmitriz> https://github.com/w3c/vc-test-suite/issues/21

dmitriz: documentation and timeouts - adding clarifying comments top readme. issues have beed fixed/addressed.

<dmitriz> https://github.com/w3c/vc-test-suite/issues/19

dmitriz: next up a couple of context issues
... has kaz fixed this?

burn: he's not on. last I heard he was working on it

<dmitriz> https://github.com/w3c/vc-test-suite/issues/18 <- same thing

<dmitriz> and https://github.com/w3c/vc-test-suite/issues/9

<dmitriz> (also same)

dmitriz: kaz mentions he's still working on those

<dmitriz> https://github.com/w3c/vc-test-suite/issues/14

burn: I will comment on them as well

issue 14

dmitriz: needs a bit more content in the readme from the issue comments. dmitriz to do this

<dmitriz> https://github.com/w3c/vc-test-suite/issues/2

issue 2

dmitriz: don't thing this applies anylonger
... that's all

burn: anything else about the test suite?

Implementation topics discussion

General Implementation Topics

burn: open floor on this topic

Implementation Guide

burn: seeing no-one on the Q

<burn> https://github.com/w3c/vc-imp-guide/issues

burn: there are both PRs and Issues
... Andrieu you started out a leader her, are you planning to continue?

deiu: maybe

burn: any volunteers to lead as editor
... you are listed as editor

deiu: I'll do it

burn: Thank you for volunteering!
... let's start w/ PRs. deiu will you start walking through them

deiu: ok

<manu> https://w3c.github.io/vc-imp-guide/

<manu> https://github.com/w3c/vc-imp-guide/pulls

<deiu> https://github.com/w3c/vc-imp-guide/pull/7

deiu: has anyone reviewed?

burn: you can ask for specific reviews by adding them as reviewers on the PR

deiu: call for general review and give thumbs up/down

burn: these are not in the spec, so we don't need the same sort of review

<deiu> https://github.com/w3c/vc-imp-guide/pull/11

burn: let's look at each and get a "next step"

<manu> +1 to merging 11

deiu: will add links to other repos

burn: looks like you can merge

deiu: I don't have the button to merge

<burn> Kaz needs to add Andrei as editor of imp-guide

<scribe> ACTION: kaz add deiu as editor to Imp-Guide
[DONE]

<deiu> https://github.com/w3c/vc-imp-guide/pull/12

ken: reviewed this one last week. one section is ready to go, others were pending

deiu: this one can be merged right?

ken: yes, merge this

deiu: we still need the JSON-LD, JWT, and ZKP sections

burn: pr12 is only a partial fix for this issue

<kaz> [kaz has just sent a GH invitation to Andrei]

deiu: leave the issue open w/ the checkboxes

<deiu> https://github.com/w3c/vc-imp-guide/pull/13

deiu: have approval by ken - editorial update

burn: has conflicts to resolve before merging

deiu: add editorial tag

bzundel will you rebase?

<deiu> https://github.com/w3c/vc-imp-guide/pull/15

deiu: editorial updates.
... looks good to merge

burn: merged

deiu: everyone please look at PR7 and give feedback
... moving to issues

<deiu> https://github.com/w3c/vc-imp-guide/issues/1

deiu: opened by dmitriz adding JSON schema

burn: why line Io/credentials?
... need a volunteer

dmitriz: suggests yancy

yancy: I guess I could, I thought jonnycrunch was doing it

<burn> kaz, please make jonnycrunch assignable on issues in vc-imp-guide

<deiu> https://github.com/w3c/vc-imp-guide/issues/2

<scribe> ACTION: kaz please make jonnycrunch assignable on issues in VC-Imp-Guide
[DONE]

deiu: need a couple examples
... dlongley can you do this?

dlongley: looking, will add examples from test suite

<deiu> https://github.com/w3c/vc-imp-guide/issues/3

burn: manu do you have anything to add or suggest here?

DavidC: when we've proven that it works we'll add it here

<kaz> [kaz has sent an invitation to jonnycrunch as well]

manu: we should mention that multiple people are working on this. demo'ed it at Rebooting last year. we can add text here
... I will not work on it until after PR

<deiu> https://github.com/w3c/vc-imp-guide/issues/4

burn: there are a variety of ways to handle this

manu: hashlinks are the "current" way but not the only way. can add text for this

burn: anyone else at digitalbazaar?

manu: Ganesh can do this, we'll volunteer him

<deiu> https://github.com/w3c/vc-imp-guide/issues/5

deiu: related to number 4 relating to non-credential data

burn: we asked if we could close this and got no reponse. will confirm/close.

<deiu> https://github.com/w3c/vc-imp-guide/issues/6

deiu: need a discussion on this before we have a resolution

burn: Brent has some ideas about this, will reach out to him

<deiu> https://github.com/w3c/vc-imp-guide/issues/8

deiu: benefits of different syntaxes and proofs

burn: manu did you write this?

manu: yes and it's been merged

ken: the PR was added and in prose

burn: last section is Olivers related to JWT

<dlongley> stonematt: At the F2F the table was getting unwieldy and we decided to do a section by section bit in prose and leave the comparison to the reader

<burn> stonematt: we recognized table was too unwieldy since couldn't agree on factors. Decided to do prose and leave the comparison to the reader

<ken> Section by section was also my recollection.

burn: content it key for now, we can reshape it later if needed

deiu: I'm happy to get the content merged in.

<deiu> https://github.com/w3c/vc-imp-guide/issues/9

deiu: re: context ordering

burn: dlongley to you...

dlongley: reading it now...
... I think this is in the spec itself.

burn: DavidC is this required in the implementation guide?

DavidC: is there a general order when you have multiple contexts

dlongley: the JSON-LD explains ordering. maybe a link to that spec

DavidC: JSON-LD isn't required, so write our own?

dlongley: if you're creating new contexts, they should be compliant w/ JSON-LD
... is there something we need to add to ImpGuide

DavidC: provide text indicating that you must understand JSON-LD context if you are creating them

dlongley: making sure we're not unnessarily adding text and that it's addressing the right issue

DavidC: this issue is about adding values and order.

dlongley: in Implementation guide, we would cover it where we describe how to create a new credential
... when the VC spec is done, there will be a new section here. I will be working on that

deiu: let's open a new issue to cover that

dlongley: ok

burn: make sure we have it documented and a "who"

<dlongley> https://github.com/w3c/vc-imp-guide/issues/16

burn: thank you

<deiu> https://github.com/w3c/vc-imp-guide/issues/10

deiu: last issue, 10, use of aliases

dlongley: close this and reference issue 16

DavidC: TallTed suggests that Uris don't require context, is that right?

dlongley: if using all URIs, don't need contexts, but this is aliases

TallTed: if you use IRI you don't need context b/c context translates to IRI.

<dmitriz> +1 for the need to clarify this

DavidC: but what about ordering?

TallTed: if context is present, then ordering matters b/c if an alias is linked twice, order matters

DavidC: al, because it defines who's IRIs takes presence
... should prevent that

dlongley: you can do that with the protected attribute

TallTed: it's better to do this case by case instead in the spec

DavidC: why?

TallTed: because we'll need to redefine things

manu: it's an open world assumption, so there are use cases where this may happen

DavidC: I get it.

<TallTed> +1

dlongley: the resolution is to mention it in issue 16 and show example of how to do simple aliases with an example, and give alternative example showing use of IRI

deiu: that's all, thank you!

burn: last of the agenda, other business?
... have a discussion about authors
... thanks all!
... bye