<stonematt> Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018Nov/0000.html
<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 :)
stonematt: We have a few items to
discuss -
https://lists.w3.org/Archives/Public/public-vc-wg/2018Nov/0000.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.
<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 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> 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, 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"
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"