<scribe> scribe: dlongley

stonematt: We've been going through PRs top to bottom and Manu as editor has been driving much of that discussion. He's not on the call today. How should we proceed? We have the standing agenda PR and lightning around issues/test suite discussion and discussion on implementation.
... But given our attendance today, is that still the right order?

oliver: I provided the PR for the JWT tests and considering that our plan is to go from CR to PR next week, I believe, to give implementers a chance to submit test reports I would like us to cover the PR for the JWT test suites.
... I don't know if it's already sufficient to submit tests.

scribenick: rhiaro

dlongley: second that, there's a related issue to do with jwt claims and issuance date so we should talk through that and make sure the test suite is doing what we want and people hvae time to write tests for it
... there's another issue, not sure if it would benefit us talking about it - ted and david c were having a discussion on github, to do with type

scribenick: dlongley

stonematt: Ok we can start with those. Let's start with the JWT PR.

<ken> https://github.com/w3c/vc-test-suite/pull/50

scribenick: rhiaro

dlongley: oliver, have you been following the discussion around using the nbf jwt claims instead of the iat jwt claims to represent issuance date?

<TallTed> https://github.com/w3c/vc-data-model/pull/646

oliver: I'm aware but don't think we came to a conlusion yet. My personal opinion is we won't change it

dlongley: the issue is the semantics for issuance date are ffectively this credential cannot be used before this time, it's not valid before this date and time, we chose a bad name for that, we intend to switch it for something like validFrom. The semantics in the spec are this credential is not valid before this time. jwt claim the best match for that is abf not iap. we have in the spec today a conflict, the issuance date says the semantics are not
... valid before this date, the jwt says use the iat claim instead of the nbf claim. we need to resolve that
... the better way to resolve that despite the poor name is to use the nbf claim for jwts because the group agrees moving forward in the future we'll deprecate issuance date in favour of validFrom
... that would also map to nbf

scribenick: dlongley

<DavidC> +1

oliver: Is the idea that `iat` won't be used in the future? It's still a common claim in the future.

<rhiaro> dlongley: jwt users could still use it. We reserved a term called issued because that was better. We reserved it in the context but we can't say anything about it normatively. In the future you could map issued to iat. You could also use iat independantly in your jwt but it wouldn't have any fields, you could map it but we can't say anything normative about that

oliver: Then I would be ok with the changes. What should be changed in the spec? Is it possible to use informative language to that?

<Zakim> dlongley, you wanted to answer and to

scribenick: rhiaro

dlongley: we have a conflict in the spec we have to clarify. This is a clarification change that does not cause another CR. the change is to say we have that conflict, issuanceDate has certain semantics which were in conflict with us using the iat claim and w eshould have used the nbf claim. Youc ould submit a PR and the group could have a resolution to change to nbf and that would solve the problem

scribenick: dlongley

oliver: In that case, I will change my tests to do this. If the group agrees to use `nbf` instead of `iat` and implementers can assume to test against `nbf`.

scribenick: rhiaro

dlongley: we should get a resolution on the call today so everyone knows that

scribenick: dlongley

`issuanceDate`

<TallTed> PROPOSED: Change spec text mapping of issuanceDate to use JWT nbf claim (with matching semantics) instead of JWT iat claim (with conflicting semantics), in parallel to testsuite change to match

<DavidC> +1

<dlongley> +1

<TallTed> +1

<ken> +1

<deiu> +1

oliver +1

<stonematt> +1

oliver: I'm fine with that. Can we merge the PR this week?

<stonematt> No ojections

RESOLUTION: Change spec text mapping of issuanceDate to use JWT nbf claim (with matching semantics) instead of JWT iat claim (with conflicting semantics), in parallel to testsuite change to match

TallTed: The PR should be mergable this week with the necessary change.

DavidC: Oliver already knows this -- we are this week testing the JWT signatures and we hope to have a conformant implementation by the end of the week.

stonematt: Excellent. So David you'll have the test report in?

DavidC: Yes, I just emailed Oliver, working on it.

stonematt: We need to pull in both PR #50 from the test suite when ready.

oliver: I will try to do it today because it's just replacing `iat` with `nbf`. And then just need someone to merge them this week.

codenamedmitri: I will merge the PR.

stonematt: These changes are to the test suite and is there a similar change and new PR in the data model for this?

oliver: I'm not aware of any, so I will have to create a new one tomorrow.

TallTed: There is a PR for this change, it needs more massage but it will be based on this resolution, PR #646 on the data model.

https://github.com/w3c/vc-data-model/pull/646

<TallTed> PROPOSED: Change spec text mapping of issuanceDate to use JWT nbf claim (with matching semantics) instead of JWT iat claim (with conflicting semantics) (https://github.com/w3c/vc-data-model/pull/646), in parallel to testsuite change to match (https://github.com/w3c/vc-test-suite/pull/50)

stonematt: any objections?

oliver: One question -- I don't have any objections, it makes sense. Are you doing the PR for the data model then?

TallTed: You can comment on that PR. I think we all understand what has to happen.

stonematt: Who is doing the typing?

oliver: I will go to the github repo and make a comment on that PR.

RESOLUTION: Change spec text mapping of issuanceDate to use JWT nbf claim (with matching semantics) instead of JWT iat claim (with conflicting semantics) (https://github.com/w3c/vc-data-model/pull/646), in parallel to testsuite change to match (https://github.com/w3c/vc-test-suite/pull/50)

DavidC: I have some good news to report, I'm at the EEMA conf on Identity, I brought up VCs here and I've added Infocert on line 16 on the implementer spreadsheet and they will fill out the columns they are implementing and I've referred them to the test suite which they are going to do as well.

<rhiaro> dlongley: manu is the author of the data model PR and he is away this week. If we want to get this moved ahead I don't think a comment on the PR will work. We might want to merge the PR as is and have oliver or tallted or whoever will do the text to change the claim name as a separate PR

oliver: The idea is to get Manu's PR merged first and then replace `iat` with `nbf`.

<rhiaro> dlongley: yes that's the plan

<rhiaro> ... and 646 is merged

<DavidC> @dlongley EU conf -> EEMA conf

stonematt: Is the next discussion is about types.

DavidC: I have a couple of issues about testing. The not transferable property ... I'm not sure there's a test for that. Anything that doesn't get two implementers will be removed, but there's no test at all.
... I put in an issue for the refresh service because it's a backdoor for the verifier to talk with the issuer.
... If we accept the refresh service in the VP but not in the VC it removes the backdoor.

stonematt: Test suite agenda item is coming up later.

<TallTed> https://www.w3.org/2019/06/11-vcwg-minutes.html#resolution02

DavidC: I think there's new information.

TallTed: Not to be too blunt but I think you disagree with the conclusion, but if you have new evidence you should present that.

DavidC: The new evidence is to go back to the minutes where strong typing was required.
... So all we need to do is clarify what associated meant but we've changed conformance from a MUST to a MAY.

TallTed: I have not found those minutes and I have been looking.

DavidC: At the time I believe Ken was arguing for it with me, but I don't know if he can recall that.

ack

ken: I believe that I had questions about whether it was supposed to be that way. I don't think I had a clear understanding of it either way.

brent: I just want to say that this is my PR, the text in the PR is my understanding of how the associated types ought to be interpreted and that understanding was agreed to by everyone on the call last week, the only one I know that disagrees with that interpretation is David.

DavidC: That is because changing strongly typed to implicit and it's totally different now from what it was before. Having any statement on type is now MAY not MUST. Once you've gone from strong typing to implicit typing you've totally changed it.

TallTed: There is nothing that prevents you as a verifier to require strong typing.

DavidC: As the test was originally it prevented implicit typing.

TallTed: I disagree and understand that's your interpretation but no one agrees with that.

DavidC: That was Brent's original understanding.

brent: That was my original understanding but I've changed my opinion.

DavidC: If we're changing from explicit typing to implicit typing we need another CR.

TallTed: But the words as they were written do not have different meaning from how they are being revised.
... We are not changing the words meaning.

DavidC: Yes we are.

TallTed: We are not changing the meaning of what was there before but you didn't think it meant that, but everyone else concurred that the meaning is what stands today.
... The wording as it stands is what this is based on.

DavidC: New text about implicit types wasn't there before.

TallTed: That is your flawed interpretation.

ken: I wanted to say that in the test suite I couldn't determine whether or not a subtype was required. I was seeking clarification about that and that came last week, and it was around the presentation. There was no ambiguity around the VC then we had the discussion and agreed with the group.

DavidC: I also agree with that.

TallTed: That's not what the text has been.

brent: I wanted to second what Ken was saying ... which is that one interpretation of the text was that a VP needed an additional subtype so in order to clarify that's not the case we needed to make it more clear that implicit typing was allowed. I believe everyone in the group understood it that way. The fact that we're having this back and forth shows that the current text isn't clear.
... What my PR does is add the line that makes that clarification according to the consensus of the group. I understand David that you disagree with that, the question is, do you formally oppose it?

DavidC: Yes I do.
... The clarification was needed for the VP it was to say that the type was not needed.

TallTed: You're still not referencing the actual paragraph which talks about all three things, VPs, VCs, embedded objects therein.
... It is not explicitly about VPs/VCs, it's to all three things. You can formally object to the resolution and the spec as it stands. But right now the text says what it does.
... Lots of people have read it and understood it to be basically as I have said. You are the only person that has had a different interpretation.

DavidC: I'm sorry, I'm not, Brent was the same as me but was persuaded to change.

TallTed: Fine, Brent changed that position to my understanding. I don't believe we'll come to resolution on this on this call.

DavidC: I did propose a resolution.

TallTed: But it would trigger a new CR.

DavidC: We've added new terms before, I don't see it as a lock up.

TallTed: I'm sorry you don't see it, but you're incorrect again. I don't think we'll come to resolution on this on the call.

stonematt: I agree, I think David if you want to object to the resolution we can do that with email or a sideline call with Burnett/Manu.

DavidC: If you give me advice then I'll follow it, thank you.

stonematt: I'll follow up on that.
... Next order of business ... are there any other issues we need to cover today?

Test Suite

dmitri: In the test suite we have no new issues. We have one that should be closed because it was addressed by last week's PR that was merged. We have two new PRs.
... The JWT one and that's waiting for the corresponding change in the data model and another PR that is just an implementation report by Yancy.
... It sounds like we merge it -- it's just an implementation report.

<dlongley> +1

<TallTed> +1

<stonematt> +1

dmitri: Issue #47 (https://github.com/w3c/vc-test-suite/issues/47) should be resolved.

<dmitriz> propose close: https://github.com/w3c/vc-test-suite/issues/47

<ken> +1 to close #47

<stonematt> +1

<dlongley> +1

<brent> +1

<dmitriz> Yancy's implementation report: https://github.com/w3c/vc-test-suite/pull/49

<TallTed> +1 close #47 as addressed y #48

<ken> +1

<dlongley> +1 to merge 49

<stonematt> +1

dmitri: So that's it for the moment.

stonematt: DavidC you had some questions/discussion.

DavidC: Two issues. One was the "not transferable" flag. If there isn't a test for it.

dmitri: This is complex human social interaction/not testable.

<rhiaro> not tested != not implemented

stonematt: One of things we've said from the beginning -- if an implementer supports that they will support it then that's evidence for keeping it in the specification.
... In the cases that there's a not an obvious test that doesn't necessarily mean that it has to go away.

<brent> just because something is not automatically testable, or is difficult to automatically test, doesn't mean it can't be normative in the spec.

DavidC: We could separate testing refresh service for VPs vs. VCs -- so we could just have support for VPs and not for VCs based on implementer feedback.

dmitri: Yes to the separation, two different sections for VPs vs. VCs.

DavidC: If we can make it two columns in the table; at the moment, if people just implement it in VPs and not in VCs then we could remove it from VCs -- that would be the reason for removing it. People could then say they support one way and not the other.

dmitri: Any objections for changing the implementation report so we have two columns for that?

stonematt: Without endorsing -- not considering the downstream issues, I don't object to that change.

ken: I don't object either, but I still don't know how to report "not implemented" because it still shows as failing instead.

dmitri: I believe the test reports have three states: pass, fail, and skip. And "skip" is did not implement.

ken: In the automated test report that is generated do I need to put that?

dmitri: I don't think so? On the vc-js test suite in the generated HTML for the test report, it's a red X for fail, green check for pass, and yellow dash for not implemented.
... I can follow up with you offline.

ken: You can follow up with my offline and give guidance.

dmitri: No problem.

brent: I don't know what Dmitri's talking about either possibly because the generated HTML doesn't work for me.

dmitri: Understood, let's connect after this -- I'll link to the HTML ones so you can see.

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

brent: But those are just for when there are no tests, right?

TallTed: Fake bad/fake good is a problem here.

dmitri: That got resolved, fake good/bad needs to be updated.

brent: I'm assuming the other implementations will each have a column as well.
... I can't speak to the accuracy of this without getting a column for my implementation.

dmitri: I'm going to open an issue to do several things. We need to connect with you afterwards.

<dmitriz> need to connect with brent to resolve the html generation issue

brent: We do have issue 30 that's related to this.

<dmitriz> yes, ok.

<dmitriz> ok, so, going back up the conversation stack -

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

dmitri: I think the action items are to clarify in the README and the UI how to distinguish fail from "not tested".
... (not implemented) vs. there is no test for it

brent: We'll need to take it offline and sort through this.

dmitri: Sounds good.

<ken> I would like to be in the offline call too @dmitri

stonematt: Any other issues with the test suite today that require discussion?

Oliver: Maybe one short question, related ... the `nbf` field and the `issuanceDate` field are both mandatory, right?

dlongley: The `issuanceDate` is mandatory in the spec.
... There is a reserved `issued` field that we can't make mandatory without going back into CR.

Oliver: Ok, got it.

stonematt: Does that meet your needs, Oliver?

Oliver: For now, definitely, once we have our spec we'll keep working on it and we should solve around `issued`.
... It's odd to have a JWT without `iat` but with `nbf`, but that's fine.

stonematt: In the implementation guide we can say that `iat` is recommended in there but not called out in the data model as a formality.

Oliver: We should add this to the implementation guide. If we talk about this `issued` field we should also talk baout `iat`.

<rhiaro> dlongley: +1 we sholud mention in the implementation guide even though it's not normative in the spec, it's best practice

<ken> Thanks to dmitri for building and improving the test suite.

<stonematt> +1

<TallTed> +1 add `issued` property and JWT iat mapping to implementation guide

<dlongley> +1

Implementations

stonematt: Where are we with implementations, who is working on them, what issues are we finding, open floor, please use the queue.

ken: Our rust implementation seems to be pretty stable in terms of getting through all the test suite issues we chose to get through, we have three things we chose not to implement and now we're just keeping current with minor changes to the test suite as it gets updated.

stonematt: I'm looking at who has submitted implementation reports.

ken: I've submitted one for the Rust Sovrin implementation.

dmitri: There is also the Evernym implementation report, one from Yancy, one pending from Oliver.

Oliver: I know that Markus Sabadello is working on one and will submit an implementation this week.

<stonematt> https://github.com/w3c/vc-test-suite/tree/gh-pages/implementations

Markus: This is Markus from Danube Tech we worked on an implementation last year using Java, including LD proofs and we updated it last week and expanded it to also support JWT proofs.

markus_sabadello: Still a lot of failures but ok to submit the report and update it later.

stonematt: What's the process for submitting?

<DavidC> I have to go now. But I have found the minutes where type was discussed, and in this @tallted was arguing for explicit typing quote "<TallTed> Implicit typing mandates inference/reasoning in tools that consume the data. Explicit typing lowers the bar for verifying, etc. I believe there are other reasons to encourage explicit typing; the only reason I know of to discourage explicit typing is the "extra" triple."

<DavidC> https://www.w3.org/2018/06/19-vcwg-minutes.html

dmitri: Just another PR, I would highly encourage everyone to submit in progress reports as well.

markus_sabadello: Thank you.

<markus_sabadello> work-in-progress implementation by Danube Tech: https://github.com/danubetech/verifiable-credentials-java

stonematt: Any other comments?
... Any other topics to cover today? We have extra time.

<ken> a+

ken: I had one PR that was in the implementation guide that I think could be merged. I don't know if we have any time to go over other PRs in the implementation guide.

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

<stonematt> who is nms in Webex?

ken: I put together a PR for the benefits of ZKP proofs and it was reviewed by Ted and Brent, it's awaiting merge.
... I don't think it's controversial.

stonematt: Any objections to pulling this one in?

no objections

ken: Thank you.

stonematt: Do we need a resolution?

<stonematt> ACTION: merge pr#12 in implementation guide: https://github.com/w3c/vc-imp-guide/pull/12

ken: We haven't been doing those for the implementation guide. But it hasn't gotten much attention in the last six weeks.

stonematt: Any other issues or topics in the implementation guide to cover?
... There are 9 open issues and 6 open PRs.

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

stonematt: Is this ready for review?

deiu: I think it was.

stonematt: I will follow up on that, I can't add reviewers.

<stonematt> ACTION: follow upon PR7 https://github.com/w3c/vc-imp-guide/pull/7 -- needs review/approve cycle

deiu: I can try to rebase it.

stonematt: Thank you.
... There's a call to action for the participants here, please go take a look at that.

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

stonematt: any objections to pulling that one in?

<stonematt> ACTION: merge https://github.com/w3c/vc-imp-guide/pull/11

none

stonematt: We have a couple of issues here from our F2F, I'm looking at ... one that Brent, you're assigned.

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

brent: I have most of a PR written, just languished as I'm doing test suite stuff.

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

scribenick: rhiaro

dlongley: on my radar now.. will be a while, i have 2 issues assigned to me

scribenick: dlongley

stonematt: Anything else today?
... Ok, we're done with the call, thanks everyone.

<stonematt> good bye all!

<ken> Thanks, matt

<James_Dz> James M Dzierzanowski, Kaiser Permanente (New Person)