- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 20 Mar 2019 02:13:11 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2019/03/19-vcwg-minutes.html
also as text below.
Thanks a lot for taking these minutes, Dave Longley!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Verifiable Claims Working Group
19 Mar 2019
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Mar/0008.html
Attendees
Present
Amy_Guy, Andrei_Sambra, Charles_Nevile, Dan_Burnett,
Dave_Longley, Ganesh_Annan, Justin_Richer, Kaliya_Young,
Nathan_George, Yancy_Ribbens, Jonathan_Holt,
Kaz_Ashimura, Brent_Zundel, Joe_Andrieu, Ken_Ebert,
Allen_Brown, Adrian_Gropper, Tim_Tibbals, Sercan_Kum,
Ted_Thibodeau, Dmitri_Zagidulin, Ned_Smith
Regrets
David_Chadwick, Matt_Stone, Tzviya_Siegman
Chair
Dan_Burnett
Scribe
dlongley
Contents
* [3]Topics
1. [4]Agenda review, Introductions, Re-introductions
2. [5]unassigned issues
3. [6]PR review
* [7]Summary of Action Items
* [8]Summary of Resolutions
__________________________________________________________
<scribe> scribenick: dlongley
Agenda review, Introductions, Re-introductions
burn: I'm going to change the agenda, I've got a proposal to
change it, let me send this out.
<burn> 1-Agenda review, Introductions, Re-introductions (5 min)
2-Unassigned issues [1] (5 min) 3-PR review [2] (20 min) 4-Open
Issues Review [3] (5 min) 5-Vote to publish CR? (20 min) Links
[1]
[9]https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&q
=is%3Aissue+is%3Aopen+no%3Aassignee [2]
[10]https://github.com/w3c/vc-data-model/pulls [3]
[11]https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&
q=is%3Aissue+is%3Aopen+-label%3Adefer
[1] http://www.w3.org/
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Mar/0008.html
[1] http://www.w3.org/
[9] https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is:issue+is:open+no:assignee
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Mar/0008.html
[10] https://github.com/w3c/vc-data-model/pulls
[11] https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is:issue+is:open+-label:defer
burn: We don't have any unassigned issues ... at least we
didn't 10 minutes ago. I hope we do not, I'll confirm. Then
we'll look at PRs and then maybe only one issue. The primary
goal today is to vote to publish a CR document.
... This is a very unusual call. Those joining for the first
time -- this is a very different call, I'll be very very hard
nosed.
... The chairs have been given conflicting info on whether this
group needs to publish a CR doc to get an extension. We
recently heard some more concerns about it. Unless someone on
this call says they will officially block CR, we are looking
for votes in support of publishing. This is to get our
extension and to continue our work that we need to do.
... If anyone is unclear about that I will ask again when we
get to the CR stage. Intros ... anyone joining us for the first
time today?
no one
burn: No reintroductions, any questions about the agenda?
none
unassigned issues
<burn>
[12]https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&
q=is%3Aissue+is%3Aopen+no%3Aassignee
[12] https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is:issue+is:open+no:assignee
burn: We have unassigned issues. I have labeled or triaged all
of them at this point. Not looking to assign anyone today,
we're trying to make sure we have time to get to the critical
item today. We can come back and get assignments at the end if
necessary.
... Any concerns with going that today?
none
PR review
burn: The next thing I want to do is look at the PRs.
<burn> [13]https://github.com/w3c/vc-data-model/pulls
[13] https://github.com/w3c/vc-data-model/pulls
burn: We have a really full crew today on the call, thank you
everyone.
... Looking at the PRs ... we have four PRs, two are ones
created in response to comments from the i18n group at W3C.
Chaals has been working pretty heavily with them over the last
24 hours. Some of those comments they wanted addressed before
entering CR and others they were ok with us delaying as long as
those editorial comments could be discussed later.
... Like edits to the examples. The goal was to get into these
PRs the number and type of changes necessary for the i18n group
to be ok with us publishing a CR doc.
... Chaals could you talk to this?
<kaz> [14]pr 469
[14] https://github.com/w3c/vc-data-model/pull/469
chaals: Sure. 469 is pretty straightforward. At this state it
just adds language information using the mechanisms that are
allowed already by JSON-LD to show how they work so people
understand that you may get information with language tagging
and you need to process it.
... 454 is purely editorial, it takes i18n considerations and
talk about things you need to think about in your work and
JSON-LD allows for a set of different approaches to managing
language information. It is currently really weak on text
direction, unfortunately, there is only one reliable way of
dealing with that and you will run into the need to do things
with text direction if you aren't stuck in your little silo and
this shows how that will work.
burn: Ok, thank you.
... Here's what's going to happen, I'm leading up to a formal
request for publishing the CR document. That proposal will say
"as amended by the PRs that we have approved today."
... So I'm going to be looking for approval to merge specific
PRs today, including those two.
... I will include those by reference.
... I understand that those are new PRs -- most of you haven't
seen them. For those who have opinions on those things, I'd
like you to take a look *now* at them.
... My first question is, is there anyone on this call you does
not believe they can make a decision on approving application
of those PRs at this time.
no one
burn: Ok. I will begin with 454.
... Any objections to us applying and merging 454,
understanding that it will become part of the CR vote later
today?
no objections
burn: No objections.
<chaals> [+1 to merge 454]
<kaz> [15]pr 454
[15] https://github.com/w3c/vc-data-model/pull/454
<TallTed> I would suggest including a day or two window for
"omg, not that!" upon seeing the doc with those PRs merged, in
the CR proposal
<burn> ACTION: merge PR 454
burn: Ted, that's a good suggestion.
... I want to ask you about that. We have a practical
consideration and that is the amount of time that we have to
allow from when we make the request and the time the
publication occurs. I would prefer not to have to do that. In
practice, I am going to be spending the rest of the day making
minor administrative edits to get it into shape for
publication.
TallTed: I'm not trying to block the CR resolution by any
stretch. It has happened to me on occasion in the past, and for
whatever phrasing didn't make sense and it ended up being
problematic in whole cloth.
... I'm between a rock and a hard place and the policies are
built that way but we're stuck with it.
burn: I need to prepare the document anyway that will go into
the transition request. That will take me at least today to do
and there is back and forth between me and Kaz, possible won't
go out until tomorrow morning. In any case, approval is not
immediate. I would like to propose that we go ahead with the
vote and the process to request publication. If, within 48
hours from this call, someone says -- "OMG, this didn't go in
the way I expected."
... "Those PRs clash in a terrible way, you've applied it
wrong" or something like that.
... Then we will cancel the transition request and do what we
need to address that. Would that be acceptable?
TallTed: Yeah, that's acceptable. I just want that small
window.
... So 30 hours of review.
burn: It wasn't 30 hours of review, it's until Thursday at this
time.
... If you want 48 hours from the time it comes out I can't
argue with that.
TallTed: That's legit.
burn: 48 hours from the time that the document is finalized
enough for us to send a transition request.
<scribe> ACTION: Dan will send out a pointer to the list for
that document.
burn: This is not for commas or minor editorial changes.
... There are typos that sometimes have to be fixed, but it's
not an open season on the spec.
(this is for OMG)
ken: Amy and I were assigned on issue 394 for normative
language in non-normative languages. One of those popped up --
and Amy brought up a list of eight items and I haven't reviewed
all of hers and there might be a problem with normative
language in a non-normative section so we might need to close
that out.
<rhiaro> Only 3 of my items were about normative text in
non-normative sections
burn: Does that mean you are making a statement that you can't
vote today for CR without those changes?
ken: No, but I don't know the rules on that.
<rhiaro> Also I think normative language in non-normative
sections are not blocking
ken: Just trying to bring that to your awareness.
... None of the other comments I filed ... I don't believe any
of the other ones are CR blockers.
burn: I'm going to make a statement that there are things that
you normally want fixed before CR -- things that you MUST fix
before CR, but what I'm really concerned about are things that
could lead us into a discussion that delay us too long to
actually have a vote.
<rhiaro> +1 chaals
chaals: Just to be clear about normative text in non-normative
section; the non-normative section is NON-NORMATIVE. It's just
a confusing editorial process rather than the universe maybe
blowing up.
ken: Thank you, I would leave it until after CR to fix that
then.
<dlongley> +1
<brent> seems like fixing normative text in a non-normative
section is an editorial change.
burn: That's also how I understand it. The section is
non-normative.
chaals: There are legitimate sensible cases where normative
language is quoted in non-normative sections.
burn: We did agree here to merge PR 454.
... So let me ask about 469. Any objections to applying PR 469
as well?
<TallTed> As I recall, *editorial* changes (typos, punctuation,
etc.) are acceptable between CR (Candidate Rec) and PR
(Proposed Rec) -- so I think those should be fine to raise at
this point; they just shouldn't be CR TR (Candidate Rec
Transition Req) blockers.
<kaz> [16]pr 454
[16] https://github.com/w3c/vc-data-model/pull/454
<kaz> [17]pr 469
[17] https://github.com/w3c/vc-data-model/pull/469
burn: So Ted is pointing out that non-normative text may be
changed in the CR phase. Between entry to CR and close of CR.
They are ok to raise at this point, I just want to make sure
that we get to a vote. They are good to know about.
... I would frankly prefer to not hear about them until we vote
about CR. I'd like to get that done. But then they are
absolutely great.
<TallTed> Yes, hold those to after the vote. My point is that
they're OK to raise during the 48hr crash-review.
burn: I have added a label into the github repo and that is
"Clarification". I don't like "Editorial". People use that to
mean non-normative. I dislike that use of the term. Editorial
is something that the editor can apply or modify at their
discretion. A clarification is also permitted between CR and PR
and that's a change that you make to non-normative text that
might require the group to agree on, so not editor doing
whatever they want.
... Use cases are a good example of that.
brent: What about a non-normative change to normative text. Or
a non-normative clarification added to a normative section.
burn: We'll get to that, let me get through the i18n PR section
first then your issue is next.
... Any objections to merging 469?
jonathan: I'm just looking at the content of the PR. Is it
really using "spans" in the JSON or is that for presentation in
the spec?
chaals: So you have a piece of HTML inside the string, that is
one of the ways in which you can identify the language
unambiguously.
jonathan: So in the VC there are HTML tags in the JSON payload.
... Is that commonly done?
chaals: Define commonly.
jonathan: I wasn't anticipating having to parse HTML.
chaals: It's a long standing practice.
jonathan: Ok, thank you.
<TallTed> inconsistent markup for those... `"alumniOf":
"<span lang='fr-CA'>` vs `"alumniOf": "<span lang='en'>`
burn: Any objections to merging PR 469?
TallTed: Not an objection, there is some inconsistency in it.
burn: A quick comment to this is fine and these two are the
critical issues for this today. Chaals a response to Ted?
chaals: Just a matter of going into the thing to get the right
brackets to show up in the doc.
jonathan: My only reservation here is that it could be a
security vulnerability. If any HTML can be there it could be a
problem.
chaals: You could, don't. Nobody accepts HTML like that.
Everyone sanitizes that and throw away bad content.
burn: Jonathan, do you need to respond to that?
jonathan: No, I'm good. I don't want to hold it up, if this is
common practice I don't want to hold it up. I was just kind of
surprised, wasn't expecting to see HTML in JSON. If there's a
better way of doing it like in the JSON-LD 1.1 spec that would
be great.
burn: CR is an implementation phase. If it turns out from
implementation that this doesn't work we should have
appropriate discussions about it.
jonathan: Right, just surprised, won't hold it up. Don't have
an expert opinion about it.
burn: Any other discussion on this PR?
... Chaals will patch the PR to deal with the bracket
inconsistency.
... We'll come back to this one because chaals will have
hopefully patched this one by then.
... Moving on.
... To the best of my understanding, we have now looked at all
of the PRs, assuming we merge the one Chaals is adjusting right
now, we've handled all the ones that could block us for CR.
... At this point, I'd like to quickly look at the other PRs
and see if there is agreement on merging them and if there's
discussion, I suggest we don't include those for CR.
... PR 460. Brent?
<kaz> [18]pr 460
[18] https://github.com/w3c/vc-data-model/pull/460
brent: 460 is in response to community feedback we got for the
ZKP section of the spec. They had just requested a bit more
clarification. I added a single block of non-normative text to
the middle of it that highlights some of the capabilities that
ZKP may enable.
burn: Any objections to merging PR 460?
no objections
<burn> ACTION: merge PR 460
burn: Let's look at PR 461. Ken?
ken: This was as I did my final read through, the statement was
that revocation shouldn't reveal information to the issuer and
I thought that was not very understandable because the issuer
already knows that information. I thought that revocation *by
the issuer* shouldn't reveal that information.
<kaz> [19]pr 461
[19] https://github.com/w3c/vc-data-model/pull/461
ken: So it's a simple two line change.
<burn> ACTION: merge PR 461
burn: Joe and David Chadwick approved this. Matt not here to
review, Tzviya emailed me to agree. I think this is a fine
change to put in. It is non-normative and editorial in
particular.
... Any objections to merge?
No objections
burn: Ok, we will merge that.
... Let me go ahead right now and merge 454.
... I'm not seeing any issues with it, I think it's editorial.
... Are they editorial or is there a lack of agreement is the
question.
<TallTed> see
[20]https://github.com/w3c/vc-data-model/pull/469/files#diff-ea
cf331f0ffc35d4b482f1d15a887d3bR4030
[20] https://github.com/w3c/vc-data-model/pull/469/files#diff-eacf331f0ffc35d4b482f1d15a887d3bR4030
<TallTed> "image": <span
class="highlight">"[21]https://example.edu/images/58473"</span>
,
[21] https://example.edu/images/58473
burn: Is it possible I've missed something?
TallTed: It's in the total file.
chaals: That's a totally different thing. Those pieces are to
highlight a particular piece of an example.
<Zakim> dlongley, you wanted to say this is editorial
chaals: You should read it in the rendered view. In the HTML in
the spec.
burn: This is editorial at this point.
<dlongley> +1 totally agree, not about disagreement
TallTed: Right, that's fine.
burn: Any objections to merging PR 469?
<burn> ACTION: merge PR 469
No objections
burn: Ok, I am merging now.
... One other thing before we do the final vote.
... Someone just opened a new issue but it's just a
clarification, that's fine.
... There is an issue we received 450 that we committed to
providing time to on this call. I have a quick question to ask
briefly. His statement is that certain concepts in this paper
are derived from 0xcert, please provide a citation for
referencing that. Brent?
brent: To sum up, I said that I wrote most of if not all of the
ZKP stuff and had never heard of them and had tried to be kind
in telling them know. I still haven't read their whitepaper so
I couldn't have quoted from it.
burn: Is there anyone on this call that is aware of specific
text being pulled from a whitepaper from this company?
ken: As helping on all of the ZKP stuff that Brent wrote, I
have also never heard of them before. If you'd like I can
comment on that as well on the issue.
<TallTed> I note they provided no link to such a
"whitepaper/techpaper" (as they describe it)
burn: Just asking a straight question. Is anyone aware of
specific text being pulled from a whitepaper?
JoeAndrieu: No. My question is -- if this is patented tech,
doesn't that matter somewhere?
burn: They stated a whitepaper or technical paper and no one is
aware of any specific text being pulled from there.
... They made a stronger statement, I don't think it's
appropriate for this group to make a determination that
something was derived from their work. Just wanted to make sure
there was no one on this call that was aware of any specific
text coming from their material.
... If no one in this group is aware of pulling text from their
papers, then I don't believe that as a group today we need to
take any specific action.
<JoeAndrieu> +1 to that call
burn: Brent has suggested that they check out the CCG and
Rebooting work and invited them to participate in our group
which is a great suggestion.
<chaals> [I have to drop in 2 minutes. +1 to move to CR]
burn: I'll put a comment to the effect that there was no one in
the group that was aware of any text being pulled from any
paper by them and closing the issue.
... Any objections to moving onto the CR vote?
No objections
burn: I'm going to make a proposal.
<burn> PROPOSED: Do you support publishing the draft Candidate
Recommendation emailed on 18 March
([22]https://lists.w3.org/Archives/Public/public-vc-wg/2019Mar/
0010.html), as modified by the PRs agreed to above, and with
such editorial changes as are needed for style, typographical
errors, or publication requirements?
[22] https://lists.w3.org/Archives/Public/public-vc-wg/2019Mar/0010.html),
<TallTed> +1
<brent> +1
<dlongley> +1 (Digital Bazaar supports the proposal)
<dmitriz> +1
<JoeAndrieu> +1
<SercaK> +1
<deiu> +1
<ken> +1
<agropper> +1
<nage> +1
<Allen> +1
<burn> +1 for Matt Stone
<Ned> +1
<burn> +1 for Christopher Allen
<burn> +1 for Tzviya Siegman
<burn> +1 for me
<jonathan> +1
<gannan_> +1
<rhiaro> +1
<JoeAndrieu> +1 for David Chadwick (via email)
<yancy> +1
<chaals> +1
RESOLUTION: Do you support publishing the draft Candidate
Recommendation emailed on 18 March
([23]https://lists.w3.org/Archives/Public/public-vc-wg/2019Mar/
0010.html), as modified by the PRs agreed to above, and with
such editorial changes as are needed for style, typographical
errors, or publication requirements?
[23] https://lists.w3.org/Archives/Public/public-vc-wg/2019Mar/0010.html),
burn: Ok, thank you very much WG.
... In the request to transition to CR, we will be pointing to
this in the minutes, which is why it's important to capture
precisely.
... I'm going to update the document with these changes and any
other minor things we realize are necessary, including the list
of changes since the last working draft.
... We will submit the transition request -- a number of people
will comment on that, chairs of WG, comm team, W3C admin,
including the director or acting director who might have
questions for me or the editors. If all of that goes well, it
will be published a week from today.
... What I'd like to ask -- people will look at our github
repo. I will try to stay on top of it.
... What I was just going to say is that it would be great if
you could hold off on sending in a flood of issues.
... If the director sees 40 issues then we have to say which
means we can do CR and which we cannot. Let's hold off until
the end of the review period, 48 hours after I send the link to
the fixed document.
... Is there anything anyone would like to discuss today, I'd
prefer not to merge anything at this point. Anything anyone
would like to discuss?
jonathan: Looking at this whitepaper I don't see any ZKPs in
their whitepaper and they'd like to have a DID method but
haven't submitted enough there -- etc.
burn: Would be good for them to be involved in the CCG it looks
like.
... Any other questions for today?
None
burn: If you have any questions about process you can say
publicly or send to me privately. If there are no other
comments, then thank you and enjoy your 6 minutes back! Talk
again next week.
Summary of Action Items
[NEW] ACTION: Dan will send out a pointer to the list for that
document.
[NEW] ACTION: merge PR 454
[NEW] ACTION: merge PR 460
[NEW] ACTION: merge PR 461
[NEW] ACTION: merge PR 469
Summary of Resolutions
1. [24]Do you support publishing the draft Candidate
Recommendation emailed on 18 March
(https://lists.w3.org/Archives/Public/public-vc-wg/2019Mar/
0010.html), as modified by the PRs agreed to above, and
with such editorial changes as are needed for style,
typographical errors, or publication requirements?
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [25]scribe.perl version 1.154 ([26]CVS log)
$Date: 2019/03/19 17:09:00 $
[25] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[26] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 19 March 2019 17:14:15 UTC