W3C home > Mailing lists > Public > public-vc-wg@w3.org > March 2019

Minutes for VCWG telecon 12 March 2019

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Fri, 15 Mar 2019 03:01:01 +0900
Message-ID: <CAJ8iq9V9O8oA31MD7ReMfm8tjNX3sDnQV8FRrCNmY_kAiXEeLg@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Thursday, 14 March 2019 18:02:11 UTC