- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 20 Feb 2019 02:49:22 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2019/02/19-vcwg-minutes.html
also as text below.
Thanks a lot for taking these minutes, Benjamin!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Verifiable Claims Working Group Meeting
19 Feb 2019
Attendees
Present
Tzviya_Siegman, Brent_Zundel, Manu_Sporny, Amy_Guy,
Justin_Richer, Dmitri_Zagidulin, Matt_Stone, Ken_Ebert,
Dave_Longley, David_Chadwick, David_Ezell,
Adrian_Gropper, Kaz_Ashimura, Joe_Andrieu, Oliver_Terbu,
Benjamin_Young, Ganesh_Annan, Ted_Thibodeau,
Allen_Brown, Dan_Burnett, Yancy_Ribbens, Ned_Smith
Regrets
Chair
Matt, Dan
Scribe
bigbluehat
Contents
* [2]Topics
1. [3]Agenda review, Introductions, Re-introductions (5
min)
2. [4]Introductions
3. [5]Unassigned issues [1] (5 min)
4. [6]Volunteer to Present to TAG (10 min)
5. [7]Implementor - Producer/Consumer (10 min)
6. [8]F2F Tentative Agenda (5 min)
7. [9]PR review (CR Blocker Checkin) (15 min)
http://www.w3.org/
* [10]Summary of Action Items
* [11]Summary of Resolutions
__________________________________________________________
<scribe> scribenick: bigbluehat
Agenda review, Introductions, Re-introductions (5 min)
stonematt: any questions about the agenda for today?
... introductions and reintroductions time
... anyone new here or anyone who would like to reintroduce
themselves?
Introductions
stonematt: no one new. how about a reintroduction?
Unassigned issues [1] (5 min)
[1] http://www.w3.org/
<stonematt>
[12]https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is%3Ai
ssue+is%3Aopen+no%3Aassignee
[12] https://github.com/w3c/vc-data-model/issues?utf8=
stonematt: the only unassigned issues here that are not
deferred is this mime type guidance
... we've talked about it in past calls
... it's a few weeks old. not a CR blocker
... can I get a volunteer, though?
brent: I volunteered last time. not sure why my name's not on
it
stonematt: sorry about that. I tried to assign it, but it
didn't work
... if anyone can help me sort that out, I'd appreciate it
manu: it typically means that brent isn't assigned to the W3C
group
... brent have you associated your github account with your w3c
account yet?
brent: yeah. I thought I did
stonematt: k. we don't have to solve it on the call today
... I mentioned brent in the comment thread. maybe you can
track it from there
... in any case, I think we have it in principle
... next item on the agenda is presentation to TAG
Volunteer to Present to TAG (10 min)
stonematt: a few items came out of an early discussion about
this
... things we might do to help move the TAG review forward
quickly
... someone suggested finding a volunteer to present our work
at a future TAG meeting
... so we're working on getting the date of their next meeting
... and looking for a volunteer to go there and present this
work to them
... given the scope of the data model, we think the TAG review
is relatively lightweight
DavidC: just wanted to ask where the meeting is?
stonematt: I don't think we need to be there in person
<dmitriz> I'd like to volunteer, to call in as well
burn: in the issue, I have made the comment that we'd like to
come and present
... but we need to wait and see if they wan to do that
... and if they suggest a call time
manu: I'm happy to be there in a support capacity
<Zakim> manu, you wanted to support w/ TAG discussion.
manu: I can be there to help navigate questions that will come
up
... but I would prefer to have someone else take point
brent: I'd be happy to take point
... since I ultimately edited the explainer, I'd be happy to
represent that
... and it would be very helpful to know manu will be there to
help navigate
stonematt: any general pointers to these volunteers?
manu: keep it high level and focused on Web architecture
generally
... you'll get questions around privacy, architecture, but
fundamentally if you stick to the explainer
... keeping it high level, we can still be ready for any tricky
questions that they may ask
... also checkout the design principles page (tnx tzviya!)
[13]https://w3ctag.github.io/design-principles/
... they will want us to understand those and talk with them in
mind
[13] https://w3ctag.github.io/design-principles/
stonematt: the next item that came out of our discussion with
Phillip, was implementation status
<stonematt>
[14]https://docs.google.com/spreadsheets/d/1SzfAUA0J72-1BORHJEm
Y4cdZrQ6vmKy4oq_24r_NwB4/edit#gid=0
[14] https://docs.google.com/spreadsheets/d/1SzfAUA0J72-1BORHJEmY4cdZrQ6vmKy4oq_24r_NwB4/edit#gid=0
<manu> Also note that many of those design principles are
specific to browsers.... so they don't apply to this work.
Implementor - Producer/Consumer (10 min)
[15]https://docs.google.com/spreadsheets/d/1SzfAUA0J72-1BORHJEm
Y4cdZrQ6vmKy4oq_24r_NwB4/edit#gid=0
[15] https://docs.google.com/spreadsheets/d/1SzfAUA0J72-1BORHJEmY4cdZrQ6vmKy4oq_24r_NwB4/edit#gid=0
stonematt: partly this is about understanding implementation
capacity
... are these implementations planning to consumer or produce
or both?
... consequently, we changed the nature of the report to match
those columns--and we'll add a "both" column also
... If you've filled this out already as an implementer, please
go back and clarify which you are: producer, consumer, or both
burn: having one producer and one consumer for each feature is
our ideal story
... at least one of each for each feature
stonematt: I'll go through the list and update the counts
... any questions about this while we're here?
manu: so. consuming is untestable
... we made the point to focus on data model, such that the
"consumer" here *is* the test suite
... we're only testing document conformance
... and not consumption per se
burn: he understands we're not testing those things
... we're really just looking for the claim that they are
producing and consuming
manu: got it. testing that both sides of the ecosystem will (in
theory) produce conforming documents that could work together
kaz: the basic idea of this procedure for CR transition
... is based in part on HTML testing
... the server provides HTML docuemnts via HTTP to the browser,
and it's rendered based on the DOM structure of the document
... the basic assumption is that somebody or some software will
process that data somehow
... if the test suite is kind of a consumer, maybe we can count
it as a consumer (implementation)
stonematt: should this idea change how we track stuff in this
sheet?
manu: if we count the test suite as one, we simply start
counting at 1 not 0.
... it's useful to tell folks this library in the test suite
will do is test the validity
... so we can't say anything about verification, etc.
... and we can't do that without heavily changing the test
suite design at this point
... I wonder if we should focus this on a data gathering
effort--it's great to know who's producing and consuming
... but then our tests can still focus on the data documents
validity
... we can use that base line validity + information about the
ecosystem to still present a clear picture of what we're doing
here together
stonematt: it might also work to help make the case for a
charter extension
manu: yes. that could be beneficial
dmitriz: there's a PR on the test suite that expands it and
fills out some of the remaining stubs
... it'd be great to have someone review that soon
<Zakim> manu, you wanted to note that that's probably my job
(but would appreciate help)
manu: that should probably be me, but I'd also appreciate
bigbluehat's review on that
<kaz>
[16]https://w3c.github.io/wot-thing-description/testing/report.
html fyi wot td report
[16] https://w3c.github.io/wot-thing-description/testing/report.html
kaz: this is mostly just FYI, but the Web of Things WG is
publishing something similar
... their implementations are also kind of classified as
consumers and producers
... their mechanism (device side vs application side) is simple
and easy to understand
... the device side generates a JSON-LD data model named WoT
Thing Description
... and the application side uses that data model to control
the device.
... so that sort of combination (somebody generates a document
and another uses that document) would help explain the
interoperability of the data model
... section 6 shows their list of implementations and section 8
shows the concrete feature coverage
stonematt: is this inline with what you were thinking, manu?
manu: no...because we focused the test suite on the data model
... and now this conversation is heading this back toward
consumer/producer testing
burn: I do not agree that's not what's happening here
manu: sure. maybe we can take this offline
... we can leave things as is, and get dmitriz's work in, etc.
... or we can rip it out and wrap it in something else to try
and test verifying, etc.
... I don't think we need to change anything to get through REC
... but if people want to say I am a conformant implementer,
then we have to change the suite
TallTed: we can't do that.
... we don't have time, and as soon as we get into the actual
implementation--and beyond the data model
... we're just testing that a document can be written that
matches this model
... if we can't test this with human eyes, then we've screwed
it up
... I understand some amount of automation is helpful
... but there's nothing that says how to do really either side
of those
<Zakim> manu, you wanted to note "yes, not a full blown
'verifier'"
manu: partial agreement with TallTed
... yes, we agreed to focus solely on data model
... so we can't go all the way to building a full-blown
verifier
... you did say one small fragment there TallTed about "doing
something" with the document
... and not fall over
... can you do something with the data model document and not
fail in some way
TallTed: if you're going to generate a document that is
verifiable, then it has to have these pieces of data in it
... if you're going to do something with that document, then it
must have these pieces in it
manu: we have tests that show they can consume the data model
... that's what the test suite currently does
... we also have a foundation that others can plug stuff into
that folks can test that the test suite is consuming stuff from
their implementations
ken: do we need to draw a line between each of the field
elements?
... do we not allow the actual verification to occur?
<oliver> +1
burn: I'm about to call chair prerogative on this to stop the
discussion.
... we do not need to do any execution on this
... manu you mentioned that you wanted to show that folks do
process these in some way
... and our conversation with Philip included that it would be
nice to promote that people say they can consume and produce
... but I don't see why the test suite needs to test or prove
any of those statements
... just the document validity--per our charter
... this is not a new realm; nothing's changed.
kaz: if we should stop the discussion here, I'm OK to stop
here, but I just wanted to mention that saying "generator" here
might be causing the confusion
... for the Web of Things work, the generator implementations
don't really "generate" the Thing Description, but the people
manually generate those docus
... and then attach that information to the devices
... and then that device exposes it to consumer applications
... it's the combination of server/client and
device/application
<Zakim> manu, you wanted to note "if you can generate, and it's
valid, the assumption is you can consume... because it's valid"
kaz: if there's a way to provide data producer and consumer,
that may simply prove that the data is portable
manu: thank you for all that input. it was very helpful
... Web of Things is actually doing something similar--just
focusing on the consumption not the processing of the documents
... if the test suite is testing validity, and you can't give
it a valid document, then you're not generating valid documents
... but if you are, then our test suite consumer will validate
that for you
... any consumer should do the exact same things that the test
suite is doing
... no need to change the test suite; we're just going to point
out lots of people are doing things with these credentials
oliver: the same question as ken earlier?
... should we implement the proof stuff in the test suite?
<Zakim> manu, you wanted to note we should implement optional
stuff in the test suite.
manu: that stuff is marked as optional in the test suite
... it's not something that you need right now
... but the last thing we want is for someone to go do JWT
stuff in a different way than what' sin the spec
... so providing guidance is important here and now
... we're tap dancing around our charter, because we still want
an interoperable ecosystem
... but the test suite can only formally test the data model
oliver: so we can add these things?
manu: yes. the test suite itself will test the validity of the
signature, etc. but your code will generate the signature
stonematt: thank you everyone for working through that
... what I heard was the test suite won't change
... and the list of producer/consumer is helpful but does not
effect how we test
F2F Tentative Agenda (5 min)
stonematt: sorry I don't have the tentative agenda done yet
... but I hope to get it out this week, so we can review it
next call
... we did go through the last list of brain stormed questions
... and we've got a high-to-low priority list
... we have a full 2 days planned
... so watch your email for more information
PR review (CR Blocker Checkin) (15 min)
<stonematt> [17]https://github.com/w3c/vc-data-model/pulls
[17] https://github.com/w3c/vc-data-model/pulls
stonematt: manu, could you run us through these open PRs?
<manu> [18]https://github.com/w3c/vc-data-model/pull/384
[18] https://github.com/w3c/vc-data-model/pull/384
manu: the group decided to move this content to an appendix, so
that's moving down
... there are a number of issues raised on the PR, and I've
updated the PR as a result
... the new text is available via:
<manu>
[19]https://pr-preview.s3.amazonaws.com/w3c/vc-data-model/pull/
384.html#proof-format-trade-offs
[19] https://pr-preview.s3.amazonaws.com/w3c/vc-data-model/pull/384.html#proof-format-trade-offs
<manu>
[20]https://pr-preview.s3.amazonaws.com/w3c/vc-data-model/pull/
384.html#pf1
[20] https://pr-preview.s3.amazonaws.com/w3c/vc-data-model/pull/384.html#pf1
manu: if you go below that section there are explanations for
ever single trade off
... still need to check grammar, etc.
... and I still need folks to provide further review
... guessing 2 more weeks of discussion before this goes into
the spec
... any more questions on this one?
... before we move to "subject only" PR, all these others are
looking good
<manu> [21]https://github.com/w3c/vc-data-model/pull/412
[21] https://github.com/w3c/vc-data-model/pull/412
manu: and I don't think they need discussion today
... 412 is the "subject only" use case
... after going back and forth with DavidC a bit, it seems
DavidC's preference is to leave the spec as is
... the reasoning behind the PR was that no implementers have
said they plan to do subject only as expressed
... the current text currently frames "subject only" via the
terms of use feature
... and there's stuff in the test suite to test it
... the approach in the PR is more complex
... but that's because it's more full featured, etc.
... the options seem to be:
... 1. we keep it as is, mark it "at risk"
... 2. we ask implementers to state their preference
... if they are interest in subject only and state which they
prefer--that would be helpful
... 3. would be to ask implementers to pick one or the
other--and if we have none, we remove the feature altogether
... DavidC had an alternative suggestion
... as implementers to pick one now
... and if they don't pick any, we leave the spec as is and see
what happens with it later
... my concern is that it's too much for the group to make a
decision on today
stonematt: can you sum up the choices at hand?
manu: the choice is a chairs call to make
... the one in the spec does not have any implementers
interested in implementing it
... the one in the PR changes it to use the termsOfUse field,
and if it's done that way, then Digital Bazaar would implement
it
... but we'd need at least one other implementer to pick one
way or the other
... so, the chairs call comes in with the "do we strike the
change?" or leave it alone
DavidC: my proposal was actually to focus on the choices of the
implementers
... if they don't pick it, then we leave it alone
... and it gets taken out if no one implements it at the end of
the CR process
stonematt: is termsOfUse also at risk?
manu: no, just subject only
... there's a simpler test to see if you've removed termsOfUs
entirely
... what we may want to do is discuss this on a call
... implementers may not be aware of the difference at this
point
... we could either take telecon time
... or we could get more folks to review the PR
... but right now we don't have enough eyes on this
burn: if I understood this correctly, at some point there will
be a doc we call CR
... there will be no features that have no implementations or
too few implementations
... I'm not keen to leave something in the spec...speculatively
... that seems like a decision to be made as early as possible
<DavidC> Manu +1
burn: the spec should be the best we have at the moment of
publication
<DavidC> Not 2 ways in the spec. Either 1 way that we know will
be implemented, or leave as is
oliver: this may be off topic, but haven't we discussed whether
we want to have comparison use case specifically?
... I wasn't able to find it in the minutes, that things should
be more use case specific, right?
DavidC: both manu and I want one way in the spec
... whatever the implementers choose
<Zakim> manu, you wanted to say no, not two into the spec, one
that we know will be implemented.
DavidC: if they don't choose, we leave what's there in place
and see what happens
manu: +1 to what DavidC said for clarifying the plans
... as an editor, though, I'm not keen to leave features in the
spec which has no support
... vs. taking an opportunity to say something about an
approach that does have an implementation
... so, DavidC it's probably up to you to drum up the support
for the subject only as described now in the spec
... with my Digital Bazaar hat on, we believe implementing the
current approach isn't worth the time as it doesn't properly
solve the use case described
<ken> +1 to subject only is a part of TOU
burn: if I understand this, manu sees this as solvable via
termsOfUse
... but if it's not done that way, and left as is, then we'd
loose the feature entirely
TallTed: given that there are 2 paths to go down
... this is a thing reasonably put in an appendix
... I'd suggest the current status quo be inverted
... the thing at risk should be put in the spec
... and the current "subject only" should go into the appendix
burn: there are ways we could handle this
... we could change it in a later version
TallTed: my concern is mostly blocking other alternatives by
leaving the feature to fall on the floor
stonematt: we'll have to do this again. Maybe on the next call
... thanks everyone! see you next week
<kaz> [adjourned]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [22]scribe.perl version 1.154 ([23]CVS log)
$Date: 2019/02/19 17:32:09 $
[22] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[23] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 19 February 2019 17:50:27 UTC