- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Thu, 8 Nov 2018 01:48:58 +0900
- To: public-vc-wg@w3.org
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