- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 11 Feb 2019 15:58:25 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2019/02/05-vcwg-minutes.html
also as text below.
Thanks a lot for taking the minutes, Dave Longley!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Verifiable Claims Working Group
05 Feb 2019
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Feb/0000.html
Attendees
Present
Dan_Burnett, Allen_Brown, Amy_Guy, Tzviya_Siegman,
Manu_Sporny, Dave_Longley, Justin_Richer,
Markus_Sabadello, Ken_Ebert, Adrian_Gropper,
Mike_Lodder, Ganesh_Annan, David_Chadwick,
Yancy_Ribbens, Gregory_Natran, Dmitri_Zagidulin,
Matt_Stone, Ted_Thibodeau, David_Ezell, Brent_Zundel,
Kaz_Ashimura, Kaliya_Young, Orie_Steele
Regrets
Chaals_Nevile, Oliver_Terbu
Chair
Dan_Burnett, Matt_Stone
Scribe
dlongley
Contents
* [3]Topics
1. [4]Agenda review, Introductions, Re-introductions
2. [5]Unassigned issues
3. [6]TAG review - privacy/security doc needed
4. [7]CR entry progress
5. [8]PR review (CR Blocker Checkin)
6. [9]Test suite checkin
* [10]Summary of Action Items
* [11]Summary of Resolutions
__________________________________________________________
<scribe> scribenick: dlongley
Agenda review, Introductions, Re-introductions
burn: Agenda for today is similar to last week, unassigned
issues, comment about TAG review, progress towards CR, then
working on PRs and issues. Time permitting we'll ask for any
updates on the test suite. Any suggestions for changes?
... Anyone joining us for the first time today?
stonematt: I have a guest, the Architect at Brightlink.
Dan Rocco: I'm here to observe and see what the WG is about.
<manu> Welcome to the group, Dan!
burn: Charles Nevile from Consensys joined today but has a
conflict so can't join. I'll let him formerly introduce himself
if/when he can make it onto a call.
Unassigned issues
dezell: I work towards/with NAACS and Conexxus continue as
co-chair at the Web Commerce Interest Group.
burn: We have a few new issues that aren't assigned to anyone.
Issue #419.
DavidC: The holder ID used to be in the presentation like the
subject ID was in the credential. It was removed for privacy
issues supposedly per the TPAC meeting but I don't remember
that. If you can figure out who the holder is from the proof in
the presentation then it makes no sense why it can't be in the
presentation.
burn: Can anyone like Brent or someone else from his team take
it?
Brent: I can take it.
burn: Next: [12]https://github.com/w3c/vc-data-model/issues/414
[12] https://github.com/w3c/vc-data-model/issues/414
Brent: I need to get a PR in for that after meeting with Dave
and Manu one more time.
burn: We can assign you though?
Brent: Yes
burn: I will take
[13]https://github.com/w3c/vc-data-model/issues/413
... [14]https://github.com/w3c/vc-data-model/issues/408
... David?
[13] https://github.com/w3c/vc-data-model/issues/413
[14] https://github.com/w3c/vc-data-model/issues/408
DavidC: It seems that there's a hole in the spec now because we
talk about holder more than subject but when we get to
verification we talk about verifying the subject not the
holder, seems like a gap that needs to be filled there.
burn: Anyone willing to take the issue?
manu: I can take the issue, I understand what he's saying and
agree with it. I will try to put a PR in, I have to go through
section 9 anyway.
burn: Thanks for taking that one.
... [15]https://github.com/w3c/vc-data-model/issues/406
[15] https://github.com/w3c/vc-data-model/issues/406
DavidC: Discussion has started about this, Joe agrees there's a
problem with the conformance statement that says this spec
can't be used without an authorization framework, etc.
<stonematt> +1
burn: Matt, I'm going to assign you to this one because you
already have a PR.
stonematt: Ok.
burn: [16]https://github.com/w3c/vc-data-model/issues/405
[16] https://github.com/w3c/vc-data-model/issues/405
DavidC: Again, discussion and PR started on this, it's
progressing well. burn: Same thing -- Matt, this is yours.
stonematt: Ok.
TAG review - privacy/security doc needed
burn: I was all prepared to write up the PR to ask the TAG to
review our spec, last Friday ... when I realized that there is
a requirement which I knew about to point to their security and
privacy questionnaire.
... But perhaps that's not the one we responded to. The one we
did before is not the current one.
... I've asked David to take a look and see what alignment
there is between the two and what it would take to apply our
responses to the current version.
... Anything you'd like to say, David?
DavidC: It would be nice for someone else to QA my work. I
would prefer so someone else would review what I say.
Dmitri: I would like to help QA it.
DavidC: I'll email you first draft and then you can give
comments.
Dmitri: Perfect, thank you.
CR entry progress
burn: Thanks guys, lots of work to get to this point and I
think that's the last piece that was missing, thanks again so
much, Dmitri and David. I will ping you pretty frequently if I
don't hear from you, please update me as often as you're able.
<burn>
[17]https://docs.google.com/spreadsheets/d/e/2PACX-1vRGJ2H4fVJD
St9G0KWhBQQiIvuB2lSRiVe5ABJcebDo_Pe-alOVtJXccjzf_dcU1tiyW2QcM0x
1Y9jh/pubhtml?gid=1319152806&single=true
[17] https://docs.google.com/spreadsheets/d/e/2PACX-1vRGJ2H4fVJDSt9G0KWhBQQiIvuB2lSRiVe5ABJcebDo_Pe-alOVtJXccjzf_dcU1tiyW2QcM0x1Y9jh/pubhtml?gid=1319152806&single=true
burn: I know Matt walked everyone through this before and these
are items that we saw were items that we needed to go through
before CR and there are items that count up and some that count
backwards from 99. There are a set of things we need now and
some right before CR (the 90s group). We've completed items
1-6. But then we came to a screeching halt.
... We voted to publish working draft but it's still not done,
a lot of is it administrative stuff. It's good we're hitting us
now because it will help us with CR. Frustrating that we're
three weeks behind though.
<Zakim> tzviya, you wanted to comment on TAG review
tzviya: I just wanted to comment on the TAG review -- I don't
think that doing the security and privacy review is required
before submitting to the TAG. I believe that the TAG finds it
kind of annoying if you give them the document right before
going to CR. They prefer more heads up. I feel that the sooner
you give them this the better. Maybe a note that security
response is pending.
burn: We can say that we completed an earlier version with PING
and say we're updating to the current version and say we'd like
to start review the now if possible, good?
tzviya: Yes.
burn: Ok, I agree with you, this is one of the blockers that
needs to happen.
... I was waiting to ping other groups until we sent something
to the TAG so this is good.
... I was going to find out from those groups if they have any
additional comments.
... This will help quite a bit, thanks Tzviya.
... After TAG review we need to close out our CR blockers. One
of the things, Manu, if you could take a look at the newly
assigned issues are CR blockers. Perhaps "gaping hole" is one
of them.
manu: Yes, I will review and mark things as a CR blocker.
burn: Yes.
manu: There will be a tension that know how to spec lawyer can
say things are editorial and aren't really CR blockers.
... The second something is marked as a CR blocker the editors
have a very strong motivation to close it out as quickly as
possible and push something into the spec for that. I'm looking
for guidance from the group... without it I'm going to be very
lenient and not mark many things as CR blockers.
stonematt: Anything that we think might affect a normative
section we mark CR blocker otherwise we can wait.
manu: Another option is punting to version 2 for certain
things.
stonematt: Maybe we want a tag for CR-2?
manu: I didn't say CR-2, I meant version 2 as in not for the
WG.
stonematt: Oh, I see.
... That's a bigger lever to pull.
manu: Yes, but one we need to start pulling, happens once you
start hitting CR.
... The group has to decide that things might be good points
put that they won't be dealt with in this version.
burn: Yes, you're correct, Manu. We're at a point where we need
to say no to new things. There's sometimes a gray area between
fixing things and doing new stuff. We already said no new
features last December. We're done with that.
... Anything that is going to be necessary in order for
implementations to implement the specification will probably
end up being a blocker either now or after CR once discovered.
I agree all sorts of editorial things can be fixed later.
... The key is that they don't change the conformance reports
that are coming in.
... Effectively.
... As you know, when you change normative behavior then you
have to have a new CR. It's perfectly fine to argue strongly
for deferral at this point, a strong argument must be made for
a change to go in now as opposed to later.
... We can't put CR-2 because that's not how CR works as
currently defined at W3C.
... Anything else on that topic?
... I will send out the request for TAG review and the request
to the other groups. Other things we do identify at-risk
features, verifying requirements met, test suite finalized,
implementation report, etc.
... I'm very concerned we won't have a CR published before the
F2F. One of the challenges for this is --- is what should we
use our time at the F2F to do? We decided to tack this onto
Rebooting for convenience. I want people to think strongly
about what would be good agenda topics because beginning next
week that will be our focus.
... That's coming up at the beginning of March.
... The charter ends at the end of March.
... We will be asking to renew the group very shortly. I would
really like to have CR published before we officially make this
request and the chairs will coordinate with Kaz before making
the request.
tzviya: I will advise you as an AB member that you should
publish CR before the request is made. It looks a lot better to
the AC if it looks like something that's more on its way. I
know as someone participating in this group that we're almost
there but it looks to the rest of the AC that there's something
that's so close to finished is fine.
burn: My understanding -- I spoke with Wendy and talked about
this and she said that an administrative extension up to 6
months does not require an AC vote. That CR in particular is
good to have but it's understood to have... in our particular
case we have major input that came in late but it's valuable
input.
... We would have been at CR now if we chose not to accommodate
JWTs or ZKPs.
<kaz> s/awell/well/
burn: But we all agree the spec is better because we
incorporated that. So the extension should not be a problem.
Despite that the chairs are working hard to get to CR.
... We have not been holding back or slacking off on this.
... Thanks, Tzviya, we're working on this.
... Any other comments?
<brent> s/awll/well
PR review (CR Blocker Checkin)
<burn> [18]https://github.com/w3c/vc-data-model/pulls
[18] https://github.com/w3c/vc-data-model/pulls
<manu>
[19]https://www.w3.org/2018/Process-20180201/#charter-extension
[19] https://www.w3.org/2018/Process-20180201/#charter-extension
<manu> Looks like what Dan just said *is* a thing...
burn: All the links are in the agenda too.
... Thanks for the link, Manu, for the up to 6 months maximum
administrative extension per the process document.
<manu> [20]https://github.com/w3c/vc-data-model/pull/384
[20] https://github.com/w3c/vc-data-model/pull/384
manu: Some of these PRs are turning out to be controversial.
They are not editorial changes. The first one is a
clarification...
... We have gotten a number of review comments in, none through
the issue tracker, but people saying they don't understand the
difference between ZKPs, JWTs, and Linked Data Proofs -- "what
should I use?". This PR was an attempt to do a factual
side-by-side comparison.
... You can/can't accomplish this with X, Y, Z.
<stonematt> maybe this is a WG Note?
manu: There is push back for putting that into the spec. It was
meant to be kind of a fairly cold analysis of what you
can/can't do today with the various proof formats.
... We need folks to weigh in on that.
stonematt: We have a couple of working group notes -- is
something like this better suited for a note?
manu: We could do it as a note, one place that we could do it
is implementation guidance. The only thing is that people might
still have the same confusion about using one or the other.
What we could do is put something in to direct people to a link
for people that want to know this stuff.
<TallTed> +1 appendix for this kind of "pick your tech, based
on your requirements" table (because appendix is definitely
linked from the main body; the NOTE would have to be published,
or at least assigned a link, before CR, to do same with a NOTE)
manu: Editorially I would like not to do that -- they are
asking that question as they read the spec and as long as the
comparison is even handed it should be fine but there's concern
there will always be bikeshedding, etc.
... Ted suggests putting it in an appendix -- which I think is
an ok compromise so it's still in the spec.
<gannan> +1 for appendix
manu: We need other people to weigh in, that PR's at a stand
still until people weigh in.
<stonematt> not CR-Blocker :)
Kaliya: I think it should go in the spec and the appendix is a
good spot for it.
manu: Anyone else have strong feelings?
<DavidC> +1
manu: Anyone feel that it shouldn't go in the spec at all? Both
Pelle and Oliver, I believe said it shouldn't go in the spec at
all.
... Any other strong opinions?
... David, what's your +1 to?
DavidC: I support putting it in the appendix.
manu: Ok, I'll rework the PR and put it in the appendix and
people can object to that if that's a problem.
<manu> [21]https://github.com/w3c/vc-data-model/pull/412
[21] https://github.com/w3c/vc-data-model/pull/412
manu: This PR has to do with the subject only property. When
David Chadwick was writing the subject-holder relationship
section. One use case was that the issue could say that the VC
should only be used by the subject and I did a PR so that could
be just another terms of use use case. I think your concern is
that ... if you're going to do that for subject only when not
for issuance date and so on.
... I think that's a legitimate push back on it -- there's a
question about where we're drawing the line in the spec. There
are things that could be modeled as terms of use and other
things where we call it out as a special property.
... So -- should we model subject-only as a special property or
put it in terms of use.
... We need to hear from implementers on this. If we postulate
a way for it to be done through terms of use it can stay in the
spec, otherwise it gets removed from the spec without
implementation support.
DavidC: When I wrote it initially I put it as a Terms of Use
thing. The problem was that the conformance statement was not
that the verifiable credential was invalid if someone else
presented it but it was the choice of the verifier. The
subject-only is independent of the protocol and who the
verifier is. Just like expiration date and issuance date.
... So it was intended to be independent of any use.
... And that had to do with conformance.
manu: I don't know if I agree with that but we shouldn't debate
it here. That's good, it gives me a different understanding of
what you were saying, let's discuss more in the issue.
... If people don't implement subject-only... I don't think DB
is planning on implementing it and we'll have to mark it as a
feature at-risk and then it will potentially be removed
entirely. I don't know which implementers will do it.
DavidC: When it was Terms of Use it was marked at-risk. Terms
of Use as such will be implemented by two or more implementers
but there may be no specific terms of use that's implemented by
two implementers where as the generic Terms of Use will be
implemented by two or more.
... It seems there's no real difference whether it's a single
property or a terms of use.
<stonematt> Implementation List:
[22]https://docs.google.com/spreadsheets/d/1SzfAUA0J72-1BORHJEm
Y4cdZrQ6vmKy4oq_24r_NwB4/edit#gid=0
[22] https://docs.google.com/spreadsheets/d/1SzfAUA0J72-1BORHJEmY4cdZrQ6vmKy4oq_24r_NwB4/edit#gid=0
manu: I think DB would at least be more willing to support it
as a Terms of Use but not as its own property.
... I don't quite know what to do with this one, you make a
good point.
... David, you're saying you'd rather have a separate property,
I'm saying DB might implement if it was a Terms of Use.
... We need more implementers chiming in -- if only DB chimes
in we know it will have to be removed from the spec. Another
option is to say "one way to do it" in the spec.
... Then it's not normative and it won't get removed as a part
of CR.
<brent> +1 to SubjectOnly being part of terms of use
DavidC: If you don't tell people how you do do it -- people
might implement things that are in the spec in different ways.
You don't get interop. If we don't say anything people do their
own thing and even when we do say sometimes they do that.
<DavidC> do that ->do not do that
stonematt: As an implementer, Brightlink is thinking about this
right now. We'll add ourselves as an implementer in the next
few days probably. I will be advocating implementing Terms of
Use internally. I think it's a market need and implementations
would prove that. If it's part of Terms of Use, it's an easy
example where I can do subject-only as a Terms of Use
implementation and it shows how to meet the two-implementation
bar for Terms of Use.
<Zakim> burn, you wanted to say we need to take offline
burn: It's time for next steps.
<stonematt> +1 leaning toward putting it in ToU, so we have a
crisp example of a useful ToU
manu: Brent wants it in Terms of Use and Matt said something to
that effect -- and it sounds like if Brightlink and DB
implement it we get Terms of Use implementations and one way of
doing it.
DavidC: It would be an excellent way of killing two birds with
one stone.
<Zakim> burn, you wanted to do chair interrupt
Orie_Steele: CTO at Transmute.
<brent> peta recommends "feed two birds with one scone"
manu: The other PRs are from matt and I think they are
progressing nicely.
stonematt: I think I responded to most of your points, not
completely aligned but good progression.
manu: Ok, that's it for the PRs.
Test suite checkin
burn: Any kind of update for us?
manu: We've had no progress on the test suite over the last
week, we're blocked on that. Ganesh/Dmitri, we either need code
to start going to the test suite or someone else has to pick
that up.
gannan: Got it.
dmitriz: Ok.
burn: Anything else before we close?
... Ok, thanks all, look forward to talking with you next week.
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [23]scribe.perl version 1.154 ([24]CVS log)
$Date: 2019/02/11 06:57:46 $
[23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[24] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 11 February 2019 06:59:32 UTC