- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Fri, 15 Mar 2019 03:01:01 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2019/03/12-vcwg-minutes.html
also as text below.
Thanks a lot for taking these minutes, Brent and Dave!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Verifiable Claims Working Group
12 Mar 2019
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Mar/0004.html
Attendees
Present
Manu_Sporny, jonathan, Andrei_Sambra, Justin_Richer,
Tzviya_Siegman, Daniel_Burnett, Benjamin_Young,
Matt_Stone, Brent_Zundel, Ganesh_Annan, David, Ezell,
David_Chadwick, Sercan_Kum, Jonathan_Holt, Ken_Ebert,
Allen_Brown, Ted_Thibodeau, Dmitri_Zagidulin,
Kaz_Ashimura, Dave_Longley
Regrets
Chair
Matt_Stone, Dan_Burnett
Scribe
brent, dlongley
Contents
* [3]Topics
1. [4]Agenda
2. [5]Introductions / Re-Introductions
3. [6]Issues and PRs
* [7]Summary of Action Items
* [8]Summary of Resolutions
__________________________________________________________
<brent> scribenick: brent
Agenda
stonematt: simple agenda today
... some conversation about anonymous presentations
... any additions or changes?
... anyone new on the line? Jonathon Holt?
Introductions / Re-Introductions
jonathan: clinical geneticist by training. work closely with
the infamous Johnny Crunch
stonematt: anyone else new?
Sercank: Greg Nutley asked me to sit in today. from <someplace
awesome>.
Issues and PRs
stonematt: unassigned issues? there are none that aren't
deferred.
... discussion today around PRs in flight. but before that, we
have a number of issues that don't have PRs
<stonematt>
[9]https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is%3Ais
sue+is%3Aopen+-label%3Adefer
[9] https://github.com/w3c/vc-data-model/issues?utf8=
stonematt: open issues not deferred.
... couple things to point out, the ones labelled CR-Blocker
are the highest priority.
... last week we added CRExit Blocker, these need to be
resolved before we exit CR
... also some horizontal review and editorial issues.
... most critical are CR-Clockers
... these need to have a PR pending
<stonematt>
[10]https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is
%3Aopen+label%3ACR-blocker
[10] https://github.com/w3c/vc-data-model/issues?q=is:issue+is:open+label:CR-blocker
manu: can we go in opposite order?
... just going over CR-BLockers and see where we're blocked.
... a number of these are blocked waiting for feedback.
... is the person assigned going to do something, or do we
close these?
... is that okay with the chairs?
stonematt: yes
<manu> [11]https://github.com/w3c/vc-data-model/issues/222
[11] https://github.com/w3c/vc-data-model/issues/222
manu: 222, Coordinate with PING
<Zakim> manu, you wanted to summarize all CR blockers.
<dlongley> brent: So this is unrelated to the ZKP stuff, this
is to write something into the privacy considerations section
regarding private browsing. I was going to ask for a copy of
feedback from PING about private browsing on the call today so
I could use that to move forward on this?
DavidC: that would be in the PING meeting minutes when they
discussed this
... we went to their group meeting.
... don't believe we ever got anything else.
<Zakim> manu, you wanted to specify what to write.
manu: they were concerned about what would happen when a
credential exchange happens in private browsing mode.
... or make sure the person is warned very thoroughly.
brent: got it.
<dlongley> brent: Most likely it will be by the end of this
week.
<manu> [12]https://github.com/w3c/vc-data-model/issues/391
[12] https://github.com/w3c/vc-data-model/issues/391
brent: PR by the end of the week.
manu: security vocab locations
<manu>
[13]https://github.com/w3c/vc-data-model/issues/391#issuecommen
t-469668035
[13] https://github.com/w3c/vc-data-model/issues/391#issuecomment-469668035
manu: we need to acquire authorization for a security
vocabulary directory, this is all on kaz.
... chairs, please ping kaz to make sure this happens.
<manu> [14]https://github.com/w3c/vc-data-model/issues/413
[14] https://github.com/w3c/vc-data-model/issues/413
manu: new is 413, Dan this is on you
<Zakim> burn, you wanted to reply
manu: please review the conformance section. I believe it is
being interpreted as talking about issuers and verifiers.
burn: the section on conforming processor, plus section 7. I
believe this is outside of the scope of our spec
... but I am going to drop it for this issue. If it comes up
again during testing and CR review, I will request the sections
be removed.
... if is shows up again during the CR review time period, I
will request they be removed or changed.
stonematt: kaz is online
manu: I raised a new issue on section 7 saying that it still
has untestable statements.
... does that address your concerns about "conforming
processor"
burn: personally, I think that is weasel wording. any comments
on processing are outside the scope of the data model.
... if the section is marked non-normative. we need to make
statements about a conforming processor
manu: I will take this and make those changes. please review
the PR to make sure I did what you just said.
<dlongley> "We expect that a conforming processor will"
burn: "it is expected that a conforming processor will ... "
manu: we can make that change
burn: make that non-normative as well.
<manu> Make sentence about conforming processor non-normative
manu: that's that issue.
<manu> [15]https://github.com/w3c/vc-data-model/issues/414
[15] https://github.com/w3c/vc-data-model/issues/414
manu: zkp section needs corrections.
... I need to review that and Ken
... there is a PR.
ken: on the previous issue, please let me and rhiaro know when
those are in, we are responsible for reviewing the conforming
language
... also I have reviewed the zkp PR.
stonematt: ken, you may have an invite somewhere from kaz to
allow us to assign you.
<manu> [16]https://github.com/w3c/vc-data-model/issues/391
[16] https://github.com/w3c/vc-data-model/issues/391
manu: going back to the one we previously discussed, issue 391.
kaz, we need a location for the security vocab.
kaz: been talking with webmaster. they'd like to manage all
redirection requests. I'm now talking with them and asking them
to create the directory for this purpose.
manu: can the chairs contact the system team?
kaz: no, the team contact needs to do it.
manu: this needs to happen very soon. when we do, let me or
Dave Longley know so we can transfer contents
kaz: sorry for the delay
<manu> [17]https://github.com/w3c/vc-data-model/issues/427
[17] https://github.com/w3c/vc-data-model/issues/427
manu: next one is related. issue 427. We don't have the file
published, etc.
... both issues are the need to have things published at the
w3c.
<manu> [18]https://github.com/w3c/vc-data-model/issues/432
[18] https://github.com/w3c/vc-data-model/issues/432
manu: issue 432. This is waiting on a PR from DavidC.
DavidC: this has been incorporated into the conformance PR.
manu: okay, we'll double check that.
<manu> [19]https://github.com/w3c/vc-data-model/issues/440
[19] https://github.com/w3c/vc-data-model/issues/440
manu: next one is a big one, can we timebox 10 minutes around
this for discussion?
stonematt: I will start the clock.
manu: we can't close this issue until the PR is in.
... brent has raised a number of issues around untestability.
We're trying to find the right level of language lawyering to
get the stuff in and close these issues.
... what we are trying to get to is conformance statements
around issuer and issuance date, things that are required.
<ken> I found and accepted Kaz's invitation.
manu: when they are specified, they must be specified in a
certain way
thanks dave
<scribe> scribenick: dlongley
<DavidC> We are saying that X MUST be presents and X MUST
contain .....
manu: Do you agree for the things that are required we can have
conformance statements?
brent: Yes, totally agree.
<ken> +1
manu: Ok, that's the first thing, we're on the same page there.
The second is a little more tricky.
... Philosophically, what we're trying to say is that we'd
really like it if you're going to express something optional,
we'd really like you to express it this way. The problem with
that is that they can express it another way because it's an
open world processor and a processor can't detect that.
... If they are using something like "myIssuanceDate" we can't
test for that. David, do you remember one of these optional
things?
DavidC: Terms of Use would be a good example of that, you don't
have to have them, but if you do you should use it.
<DavidC> we are saying that optional items are MAY be included
but if it is there is MUST contain ...
manu: Right, if you do include it, you must include its type,
for example.
... Philosophically, are you ok with attempting to say "If you
are going to express it, do it this way"?
brent: I don't have a problem with that. So the problem came up
for me when ... we attempt to say, "If a conforming VC must
express the date that the VC was issued using the date
property". That statement is untestable.
... It's testable to say that the issuanceDate property must be
present or that the expected use is to be the date or the date
value MUST be an RFCxxxx whatever. Those are testable.
<burn> Brent is correct
brent: I cringe when we try to require conformance to
intention.
<burn> mandating how/when to use is a problem. mandating format
when used is acceptable.
manu: It's clear. I'm trying to figure out a way of basically
saying... the testable portion is to make sure that they at
least use the field. They aren't taking the field, deleting it
and changing it to something else. It's fine to express
issuanceDate in your own way, but if you are given a
protocredential you have to preserve it.
... You can't override or delete it. I know that that is a bit
of a difficult ... I think that's testable. If you have an
input file you can't remove those things.
jonathan: On the flight back I had an epiphany on the
interplay. With VC+JSON these things are mandated ... we
conform on application/json and in that form, in that
transformation we have to have things in a full format
including scheme definitions. When you use JWT it serializes
and is implicit in the specification. A lot of the spec is
readable for JSON, it's human readable but it gets lost in
translation when we transform it from one MIME type to
another.
brent: What we need to be able to say is "this property must be
included" and we can say that the expected value of this
property must be a URL, but what we can't say is that type
information must be expressed using the type property. You can
say you have to have a type property and it must be a URL and
here are the objects that must have a type specified, but you
can't say how it must be used.
<burn> +1 brent. mandating how/when to use is a problem.
mandating format when used is acceptable.
brent: That's protocol and a level above what we can talk about
and it's not testable from a data model perspective.
<burn> yes, can say "must be present" and "must contain". it's
"must mean" that we can't do.
DavidC: I actually disagree with Brent there. We can say that
the type must be there and it must contain a URI. We can't
mandate that the URI is correct but that it must be one. What
I've done is suggest some wording in the chat minutes. If we
agree this must be present and it must contain -- two musts --
for something like terms of use it may be present but it must
contain. The only hole we've got in that is that it may be
present. We can't stop others
from using another way to express terms of use.
DavidC: But if they do specify our terms of use they have to do
it the right way.
brent: I would go a step further, we can't even say it for the
required fields -- we can't say they must be used in a certain
way.
DavidC: I think we can.
<Zakim> TallTed, you wanted to say "you can't do xyz" is
PROTOCOL
<burn> +1 Ted
<brent> +1 Ted
<stonematt> +1 TallTed
TallTed: We absolutely cannot say "you cannot use this in this
way". That is protocol, use, that is action. This field must be
present, the values must be that, fine, great. We can't say "if
you see this field you have to use it like this" or "if you see
this field and translate it this way this must be your result"
except possibly between serializations.
<brent> scribenick: brent
TallTed: I cannot fathom why very intelligent people keep going
down these rabbit holes
<Zakim> manu, you wanted to ask brent and DavidC to work it out
in the PR :) -- with concrete language. and to
TallTed: we are nowhere near solid enough
manu: Brent, David, please figure this out in the PR
<DavidC> will do
will do
<DavidC> +1 TallTed
manu: please, very active conversation this week
<burn> Brent and Ted are correct. This is not an opinion. This
is reality.
<manu> [20]https://github.com/w3c/vc-data-model/issues/444
[20] https://github.com/w3c/vc-data-model/issues/444
manu: 444 is simple PR. we have wide buy in. I will do a PR for
that.
... this may be part of the big PR as well. 443.
<manu> [21]https://github.com/w3c/vc-data-model/issues/446
[21] https://github.com/w3c/vc-data-model/issues/446
manu: I will take it and do that PR
... next is 446. I re-read section 7 in depth. it has
conformance statements that need to be cleaned up.
... we could take care of all of these this week.
Brent and David need to get together on this.
manu: I can go in editorially afterwards
DavidC: what about the proof being mandatory in one part of the
spec and not another?
manu: if that is still an issue, please raise it.
burn: brent and ted are correct. this is not opinion. we have
let the group go on and one. we are at the point where if there
ends up being a dispute again.
... I will defend that to the director of w3c. I hate being
arbitrary, but this has got to stop.
<manu> me :)
<stonematt> [22]https://github.com/w3c/vc-data-model/issues/435
[22] https://github.com/w3c/vc-data-model/issues/435
stonematt: feature request. anonymous presentations
... we had a feature freeze last fall, nothing to add to the
spec now.
<brent> +1
<burn> +1 manu
manu: we are not preventing this in the future. the data model
should support this in the future
<stonematt> [23]https://github.com/w3c/vc-data-model/pulls
[23] https://github.com/w3c/vc-data-model/pulls
stonematt: manu anything to add to PR review?
manu: jonathan good thing you're on the call. I would like to
drop the IPLD PR, based on what we discussed in Barcelona.
Would you object to that?
jonathan: I will close it and re-open it so it is more clearly
about CBOR.
... we're settling on JSON because it is more human readable.
... this is where the MIME types would be really useful.
<manu> [24]https://github.com/w3c/vc-data-model/pull/261
[24] https://github.com/w3c/vc-data-model/pull/261
jonathan: behind the scenes IPLD is CBOR. So I will re-submit
as CBOR and give a JSON serialization of it.
manu: will review ZKP
... brent and David C, please get together on the conformance
PR
... the one from Grant is editorial
stonematt: covered a ton, thank you
<Zakim> burn, you wanted to explain that chairs marked ipld as
defer as a new feature request
burn: the ipld PR was marked as defer and feature request. we
will look at what you send in, but we are not going to add any
new syntaxes and formats.
... as long as you are not prevented from doing what you need,
that can be added in the future.
jonathan: as long as we can all agree on the JSON, we can
serialize that as we need to
stonematt: no other business. thanks for your focus and work to
get this done.
<stonematt> thanks all
<kaz> [adjourned]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [25]scribe.perl version
1.152 ([26]CVS log)
$Date: 2019/03/14 17:55:59 $
[25] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[26] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 14 March 2019 18:02:10 UTC