Minutes for VCWG telecon 18 June 2019

available at:
  https://www.w3.org/2019/06/18-vcwg-minutes.html

also as text below.

Thanks a lot for taking these minutes, Dave and Amy!

Kazuyuki

---

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                    Verifiable Claims Working Group

18 Jun 2019

   [2]Agenda

      [2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Jun/0007.html

Attendees

   Present
          Amy_Guy, Andrei_Sambra, Brent_Zundel, Dave_Longley,
          Justin_Richer, Kaz_Ashimura, Ken_Ebert, Matt_Stone,
          Sercan_Kum, Ted_Thibodeau, David_Chadwick,
          Markus_Sabadello, Jonathan_Holt, Ned_smith,
          Dmitri_Zagidulin, Oliver_Terbu

   Regrets
          Tzviya_Siegman, Charles_McCathie_Nevile, Yancy_Ribbens

   Chair
          Matt_Stone

   Scribe
          dlongley, rhiaro

Contents

     * [3]Topics
         1. [4]Test Suite
         2. [5]Implementations
     * [6]Summary of Action Items
     * [7]Summary of Resolutions
     __________________________________________________________

   <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> [8]https://github.com/w3c/vc-test-suite/pull/50

      [8] 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> [9]https://github.com/w3c/vc-data-model/pull/646

      [9] 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.

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

     [10] 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)
   ([11]https://github.com/w3c/vc-data-model/pull/646), in
   parallel to testsuite change to match
   ([12]https://github.com/w3c/vc-test-suite/pull/50)

     [11] https://github.com/w3c/vc-data-model/pull/646
     [12] 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)
   ([13]https://github.com/w3c/vc-data-model/pull/646), in
   parallel to testsuite change to match
   ([14]https://github.com/w3c/vc-test-suite/pull/50)

     [13] https://github.com/w3c/vc-data-model/pull/646
     [14] 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>
   [15]https://www.w3.org/2019/06/11-vcwg-minutes.html#resolution0
   2

     [15] 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
   ([16]https://github.com/w3c/vc-test-suite/issues/47) should be
   resolved.

     [16] https://github.com/w3c/vc-test-suite/issues/47

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

     [17] 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:
   [18]https://github.com/w3c/vc-test-suite/pull/49

     [18] 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>
   [19]https://w3c.github.io/vc-test-suite/implementations/#confor
   mance-testing-results

     [19] 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> [20]https://github.com/w3c/vc-test-suite/issues/30

     [20] 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>
   [21]https://github.com/w3c/vc-test-suite/tree/gh-pages/implemen
   tations

     [21] 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> [22]https://www.w3.org/2018/06/19-vcwg-minutes.html

     [22] 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:
   [23]https://github.com/danubetech/verifiable-credentials-java

     [23] 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> [24]https://github.com/w3c/vc-imp-guide/pull/12

     [24] 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:
   [25]https://github.com/w3c/vc-imp-guide/pull/12

     [25] 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> [26]https://github.com/w3c/vc-imp-guide/pull/7

     [26] 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
   [27]https://github.com/w3c/vc-imp-guide/pull/7 -- needs
   review/approve cycle

     [27] https://github.com/w3c/vc-imp-guide/pull/7

   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> [28]https://github.com/w3c/vc-imp-guide/pull/11

     [28] https://github.com/w3c/vc-imp-guide/pull/11

   stonematt: any objections to pulling that one in?

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

     [29] 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> [30]https://github.com/w3c/vc-imp-guide/issues/6

     [30] 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> [31]https://github.com/w3c/vc-imp-guide/issues/4

     [31] 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)

Summary of Action Items

   [NEW] ACTION: follow upon PR7
   https://github.com/w3c/vc-imp-guide/pull/7 -- needs
   review/approve cycle
   [NEW] ACTION: merge https://github.com/w3c/vc-imp-guide/pull/11
   [NEW] ACTION: merge pr#12 in implementation guide:
   https://github.com/w3c/vc-imp-guide/pull/12

Summary of Resolutions

    1. [32]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
    2. [33]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)

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [34]scribe.perl version 1.154 ([35]CVS log)
    $Date: 2019/06/25 06:36:02 $

     [34] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [35] http://dev.w3.org/cvsweb/2002/scribe/

Received on Tuesday, 25 June 2019 06:38:10 UTC