Minutes for VCWG telecon 6 November 2018

available at:
  https://www.w3.org/2018/11/06-vcwg-minutes.html

also as text below.

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

Kazuyuki

---

   [1]W3C

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

                               - DRAFT -

                      Verifiable Claims WG Meeting

06 Nov 2018

   [2]Agenda

      [2] https://lists.w3.org/Archives/Public/public-vc-wg/2018Nov/0000.html

Attendees

   Present
          Brent_Zundel, Clare_Nelson, Ganesh_Annan, Manu_Sporny,
          Matt_Stone, Tzviya_Siegman, Ken_Ebert, Kaz_Ashimura,
          Benjamin_Young, Oliver_Terbu, JoeAndrieu, Dave_Longley,
          David_Chadwick, Kim_Duffy, Ted_Thibodeau, Allen_Brown,
          Yancy_Ribbens, Christopher_Allen

   Regrets
          Dan_Burnett

   Chair
          Matt_Stone

   Scribe
          manu, dlongley

Contents

     * [3]Topics
         1. [4]Introductions
         2. [5]CR Blockers and Other Issues
         3. [6]Pull Request Processing
     * [7]Summary of Action Items
     * [8]Summary of Resolutions
     __________________________________________________________

   <stonematt> Agenda:
   [9]https://lists.w3.org/Archives/Public/public-vc-wg/2018Nov/00
   00.html

      [9] https://lists.w3.org/Archives/Public/public-vc-wg/2018Nov/0000.html

Introductions

   <manu> scribenick: manu

   oliver: Hi Oliver Terbu, work at ConsenSys/uPort - not my first
   call, following calls. We're very interested in using VC,
   looking forward towards interop. Saw that there is a need for
   JWTs, there are alredy a lot of comments on that, looking
   forward to working with the group on that.

   stonematt: Welcome to the group :)

CR Blockers and Other Issues

   stonematt: We have a few items to discuss -
   [10]https://lists.w3.org/Archives/Public/public-vc-wg/2018Nov/0
   000.html
   ... We are at Nov. 6th - this is the day that we set out to
   feature freeze data model in order to get to CR.
   ... I want to clarify what that means - there were 3 issues
   that we brought up and identified at W3C TPAC that we indicated
   we wanted to get closure on before CR... those 3 things were
   reconciling for ZKPs, terms of use, and JWTs.
   ... The first thing I want to do is validate that these are the
   3 open issues that are still in flight and that there is not a
   fourth.
   ... Any objections to close significant discussion on other
   topics?
   ... I want to make sure we don't have a fourth.

     [10] https://lists.w3.org/Archives/Public/public-vc-wg/2018Nov/0000.html

   <inserted> scribenick: dlongley

   manu: I'm not saying we have a 4th; I haven't been able to
   review things. My hope is that anything that is marked with CR
   blocker is in that list of things before going into CR. In the
   issuer tracker, if something is marked as needing to be done
   before going into CR then we'll work on that before we call the
   CR.
   ... Is that the understanding?

   <inserted> scribenick: manu

   stonematt: Yep, that's the understanding.
   ... The CR Blocker tag and these three items are the worklist
   that we have.

   DavidC: Yes, supporting what Manu said, there are still some
   things that are not resolved yet and they do need to be
   resolved - one of them is to do w/ subject id and the modeling
   of VCs.
   ... There are some things about delegation that need fixing.

   stonematt: As long as we're working under the auspicies of CR
   Blocker, we're good.

   TallTed: Regrettably I wasn't at the F2F and last couple of
   weeks have been insane, haven't been able to put in as much as
   I want to do.
   ... I want to make sure we are focusing on the model... in
   subject not equal to holder, the graphical sketches that we
   have, graphical sketches should be easy to do...
   ... The higher level handwave boxes do not communicate a model,
   there is a lot of overlap... a lot of it between David and
   myself, I think we agree more than we disagree, but it's not
   clear by what's being communicated.

   <Zakim> manu, you wanted to note images need to change.

   TallTed: We are largely focusing on putting W3C stamp on thing
   that companies are doing as a product, and it's valuable and
   good, but we need to produce something that is more inclusive
   than that.

   <inserted> scribenick: dlongley

   manu: I agree with Ted. There continues to be miscommunication
   around the model and images could help. The images that Ted is
   pointing out are high level and hand wavy. Maybe drawing the
   graphs would help. Part of the issuer may be is that there's
   disagreement on "claims".
   ... Claims pointing to a graph of information and how do we
   represent it.

   <DavidC> The issue is even if the claim should point to a
   separate graph or not

   manu: Ted's point is taken, we could generate a bunch of
   different graphics and see if both Ted and David agree that
   it's what's in their head. I expect that that won't be what
   will happen though. There are two ways of looking at the spec
   and both are valid.
   ... David is saying he shouldn't have to know much about
   JSON-LD to put things into the data model.
   ... Learning things at depth shouldn't be required and people
   should be able to just slot things in.
   ... That's David's position. Ted's is that the details matter
   and we need to show people all the complexity and the people
   that do read the specification come away with a very clear
   understanding of exactly what the data model is doing and that
   means exposing people to things like @graph containers and why
   being able to make statements about other graphs of information
   is key to the data model.
   ... I think we can maybe address some of this stuff in a
   non-normative way if we get into CR. I think the key problem
   right now is that we could make a pretty big change before we
   jump into CR. I imagine if we jump into CR at this point it's
   going to be with the data model we have right now and maybe not
   the one that David Chadwick and Dave Longley are looking at
   right now. There's stuff that might get David Chadwick wants
   but with less testing.
   ... The only thing I can propose is that we create some
   pictures and see how David Chadwick react to that.

   stonematt: I'm going to generally agree.

   <inserted> scribenick: manu

   stonematt: I agree, in general, one of the things we might
   decide right now is decide the audience of the document.
   ... a big audience are going to be implementers that are
   building core libraries and products that use this data model.
   ... That kind of demands more technical specificity. We want
   something like a primer to be more generally accessible by the
   layman.

   <tzviya> +1 to stonematt

   stonematt: If we hide the details, we're doing the community a
   disservice.

   <tzviya> have you considered
   [11]https://w3ctag.github.io/explainers?

     [11] https://w3ctag.github.io/explainers?

   DavidC: The model should be as complex as it needs to be but no
   more complex... I think it's more complex than it needs to be.
   I'm also worried about millions of people using it, defining
   their own VCs, and won't get confused w/ the ID of the claim
   being the subject of the ID.

   <Zakim> manu, you wanted to say that's exactly the wrong way to
   write specs. :P

   <inserted> scribenick: dlongley

   manu: So I'm probably going to argue against what most people
   have said to date. I think primers and explainers have their
   place but it's a terrible way to write a technical
   specification. We made it, for JSON-LD, so Web developers could
   read the spec and understand at a high level what was going on
   and they could go to the advanced section to drill into the
   details.

   <stonematt> +1 to go into more detail later in the document

   manu: The mistake that most W3C and IETF specs make is that
   they assume it's only for implementers. If a dev can't read the
   first few pages and understand what you're doing then you've
   failed. The VC spec suffers because it hand waves at the
   beginning. We wanted to be able to point a Web dev at the spec
   and let them understand the high level at the intro. We didn't
   go into the details and that's where we fall down but we can do
   that in the advanced section.
   ... For example, we gathered around a whiteboard at TPAC and
   Dave Longley explained @graph containers and people finally got
   it and we should put that in the spec but not lead off with it.
   ... That level of complexity is for advanced concepts. -1 to an
   explainer, -1 to a primer, fine if those exist, but I disagree
   very strongly with removing that same content in the lead in in
   the specification.
   ... I think that's lazy -- not saying anyone is doing that but
   that's what that effectively is.

   <inserted> scribenick: manu

   TallTed: In response to Manu, it's an order of operations thing
   - you can't write a technically detailed document of any size
   starting from the handwave unless you actually understand the
   deep core.
   ... Say if you're writing a nuclear physics text, if you don't
   understand the interaction between atoms, you cannot write the
   handwavy part that gets people passing understanding where you
   do the deep dive later.
   ... You have to know about the quarks/protons/etc... if you
   don't, you end up talking about earth, air, fire, water...
   which is a fine construct, but it doesn't get you to iron,
   sodium, lithium, etc.

   <kimhd> I'd be happy to help vet whatever we come up with (but
   not develop it, because I don't understand enough). Via
   Blockcerts users, I think I have a good feel for what trips
   people up (including myself)

   TallTed: The starting point needs to be the depth.
   ... I haven't seen a representation of that core, clearly
   understood, in that spec. If it's that well understood, it
   should be clearly communicable to those on the call.
   ... There will be millions of people using it at a high
   level... they don't need to understand at depth, but the folks
   doing implementations need to understand at depth.

   <Zakim> manu, you wanted to propose a way forward.

   <inserted> scribenick: dlongley

   manu: I actually agree with Ted on this. One thing we can try
   is to put the deep stuff in the advance section and really just
   go into as much depth as we need there and if folks don't feel
   like it's adequate, we can always move it into the
   introduction.
   ... We can split the introduction section and say we'll talk
   about earth/wind/fire and then the next section can talk about
   quarks.

   <DavidC> +1

   <bigbluehat> +1

   manu: The only solution to this is to go into more depth,
   explaining the technology. And once we do that and everyone
   agrees -- moving it around after we hit CR is just an editorial
   endeavor. So add more diagrams and language to the advanced
   section, specifically around @graph containers and the like.

   TallTed: I would go with that.

   <TallTed> +1

   stonematt: I like that idea.

   <kimhd> +1

   <inserted> scribenick: manu

   stonematt: We want to make sure it's not too generic, that
   won't be helpful.

   <dlongley> +1

   stonematt: We might find a medium level detail isn't going from
   0 to 10... maybe there is a 5... once 10 gets written.

   <TallTed> +1

   manu: +1

   stonematt: Do we have that represented in an issue that has CR
   blocker?

   <inserted> scribenick: dlongley

   manu: I'll try and find an issue related to this.
   ... It's rename `claim` to `subject` ... but that's not really
   the issue, I'll raise a new one.

   <manu> [12]https://github.com/w3c/vc-data-model/issues/268

     [12] https://github.com/w3c/vc-data-model/issues/268

   stonematt: While you're doing that, with that addition, is
   there consensus/any objections to saying this is the list,
   those with CR blocker on it, that we're driving to address
   before CR?

   no objections

   <inserted> scribenick: manu

   DavidC: What about issues that are not marked as CR blocker,
   but are related...
   ... For example,
   [13]https://github.com/w3c/vc-data-model/issues/240

     [13] https://github.com/w3c/vc-data-model/issues/240

   stonematt: There are a couple of ways forward, we can defer, or
   we decide that it's not required for CR, but we're going to
   keep working on it because it's not substantive... or we add it
   to the list.
   ... So there may be other things that come up that should go
   into the spec, but that should be a high bar.

   DavidC: Can we go through that list now?

   <kimhd> we did that right after you left DavidC

   <inserted> scribenick: dlongley

   manu: I'm looking at them now, we did already do that at TPAC.
   But it's not clear by looking at it. When we were processing
   them before, the ones that needed a PR, it seemed like there
   was closure and we knew what was needed to be written. So in
   general, we just need to write spec text for those with "Needs
   PR".

   <Zakim> manu, you wanted to suggest adding it to the list.

   manu: Then the question is if ... once the spec text is in,
   whether or not it's a CR blocker. I'd like the editors and
   chairs to determine if it's a CR blocker.
   ... We have 11 of these, if every one of these becomes a CR
   blocker that's another month or two of work. Can we avoid going
   through the list again?
   ... The ones that have "needs PR" are probably straightforward
   and we can write spec text -- but if people object we can then
   determine at that point if we're dropping or not.
   ... Can we do it that way?

   DavidC: Let's proceed then -- and I'll try to do some text to
   help as well.

   <inserted> scribenick: manu

   Ken: I had a question on issues that are on issue tracker
   board, such as 206, that appears to be on the board, but it
   doesn't have a CR Blocker and it already has a PR. Am I
   misinterpreting the board, or is that unintentional.

   <stonematt> potentential Resolution: Use the GitHub project
   "get to CR" and the issues that are labeled "CR-Blocker" as the
   scope for CR transition - chairs to review issues w/ "Needs PR"
   as potentially "CR-Blocker"

   stonematt: We're lookign at the combination of those lists.

   <inserted> scribenick: dlongley

   manu: That one is no longer a CR blocker, seven days ago we
   removed the tag on that one. So, Ken, yes ... that should
   probably no longer be in the CR blocker list, because the stuff
   that was blocking us is now in the spec. But there are some
   other clean up things that need to be done, for example,
   requesting a URL from W3C team and document some other things
   that don't block us from going to CR.

   <inserted> scribenick: manu

   stonematt: We have a requirement to make another list for
   things that need to happen, but are not blocking CR.

   <stonematt> ACTION: make second project in GitHub to include
   work required to close the group, but not required for
   transition to CR

   manu: +1 to that :)

   RESOLUTION: Use the GitHub project "get to CR" and the issues
   that are labeled "CR-Blocker" as the scope for CR transition -
   chairs to review issues w/ "Needs PR" as potentially
   "CR-Blocker"

Pull Request Processing

   stonematt: We have a new PR for JWTs... Brent has a few
   examples on ZKPs...
   ... Those two items are addressing open issues wrt. features we
   want to address. We also have a Terms of Use discussion that
   doesn't seem well scoped/bounded. I don't see a clear issue
   that is Terms of Use.
   ... I need to draw a boundary around Terms of Use issue...
   those are the three things... how can we best use our next 12
   minutes

   <dlongley> DavidC: I thought you had a really good response to
   Terms of Use.

   DavidC: I think you had a good response to ToU - made a
   suggestion on ToU discussion, not in an issue, maybe we open it
   as an issue w/ that text, so we can hang issues/PRs off of
   that.

   manu: +1 to oepning it as an issue.

   <inserted> scribenick: dlongley

   manu: I'd prefer talking about the JWT stuff. I see Brent is on
   the queue too to talk about the ZKP stuff, but I don't think
   the ZKP stuff is controversial whereas the JWT may be.

   <brentz> +1

   manu: I think the PR creators should intro their PRs.

   <TallTed> +1 for issue, as most discussion has been pushed from
   standard mailing list into issues

   <inserted> scribenick: manu

   stonematt: Let's time box topics to 5 minutes... JWTs and ZKPs.

   brentz: The PRs wrt. ZKPs, 214 and 217 - I think we have rough
   consensus, some bikeshedding on 214... if people want to change
   text, they should propose their own PR after we merge it. I
   think we have good agreement on 217. 262 has been in there for
   a little while, adds privacy paragraph.
   ... I had a comment on 258 that was merged, part of my comment
   may have been my own lack of understanding on URI definition...
   wrote 263 in response to it, single line of text that a URI is
   not necessarily a DNS-style link. Perhaps that text is
   unnecessary

   manu: That text is unnecesarry :P

   brentz: 265 is adding a few examples for PING
   ... They wanted examples that highlighted ZKPs, left them in
   there w/ pre-existing examples so they can be
   compared/contrasted. Some text is clarified in the PR so
   examples make a little more sense. Those ar ethe ZKP PRs.

   oliver: I recently put in JWT PR... There was a suggestion to
   remove it from spec for CR... had conversations at RWoT and
   IIW, at SF, implementers who wanted to support JWTs... also
   stated in corresponding issue. Personally, JWTs will facilitate
   easier integration w/ legacy systems... *losing audio*
   ... beneficial to have JWT representation in space based on
   conversations we had with RWoT and IIW - JWT will facilitate
   integration w/ traditional legacy systems, many different
   libraries supporting JWTs already, tackle some issues w/ JWT,
   Manu and DaveL already commented on PRs.
   ... Hope we can find solution we're all happy with.

   <Zakim> manu, you wanted to note challenges w/ JWT issue... and
   suggest way forward.

   <inserted> scribenick: dlongley

   manu: Yes, so the ZKP stuff just needs review, I don't think
   it's controversial. The JWT stuff ... a couple of ways to move
   forward there is to mark it at-risk or likely to change during
   CR and that let's us go into CR while still refining it.
   ... The other way to do it is to have a long list of issues
   with the JWT based approach. I think we outlined 8-9 issues
   that are created by using JWTs ... at the same time if there
   are implementers that want to use them the group shouldn't
   stand in the way but be very clear about where things fall
   apart with that approach.
   ... I think it's up to you, Oliver, to decide how to get the PR
   in there. Maybe mark it `at-risk` and we mark concerns and
   during CR we try to refine it. Or we just say "these are all
   the risks and we don't have a way to address them" and leave it
   at that.

   oliver: So we mark at-risk and try to address the issues or
   just list them all and say that they exist if you use JWT.

   <inserted> scribenick: manu

   stonematt: Let me add to that - there are a couple of different
   ways to think of that approach - list of problems is negatively
   prejudicial - in these use cases, JWTs are equivalent... maybe
   once you move outside of those use cases, things are fine...
   maybe we can cast them in a more positive light.

   oliver: i'll try to write where JWTs are equivalent...

   <dlongley> notes that it's not really JWT vs. JSON-LD, both are
   using JSON-LD, it's whether "proof" is used or JWT is used
   (unless we can find some common ground there too)

   manu: I'm not sure it's even about that :(

   stonematt: This is opening old discussions again... let's keep
   the focus on and keep going.

   <stonematt> ACTION: Chairs to review issues with "needs PR" for
   items that may be "CR-Blocker"

Summary of Action Items

   [NEW] ACTION: Chairs to review issues with "needs PR" for items
   that may be "CR-Blocker"
   [NEW] ACTION: make second project in GitHub to include work
   required to close the group, but not required for transition to
   CR

Summary of Resolutions

    1. [14]Use the GitHub project "get to CR" and the issues that
       are labeled "CR-Blocker" as the scope for CR transition -
       chairs to review issues w/ "Needs PR" as potentially
       "CR-Blocker"

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [15]scribe.perl version 1.154 ([16]CVS log)
    $Date: 2018/11/07 16:45:34 $

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

Received on Wednesday, 7 November 2018 16:50:04 UTC