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

Minutes for VCWG telecon 2 April 2019

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Mon, 8 Apr 2019 00:43:44 +0900
Message-ID: <CAJ8iq9V1_VaPsq1F4rGi-AgPxB06Yfe1apyfu6CmE0uDT_frwA@mail.gmail.com>
To: public-vc-wg@w3.org
available at:
  https://www.w3.org/2019/04/02-vcwg-minutes.html

also as text below.

Thanks a lot for taking the minutes, Ganesh and Dave!

Kazuyuki

---

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                    Verifiable Claims Working Group

02 Apr 2019

   [2]Agenda

      [2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Mar/0030.html

Attendees

   Present
          Dan_Burnett, Dave_Longley, Ganesh_Annan, Justin_Richer,
          Manu_Sporny, Tzviya_Siegman, Brent_Zundel, Amy_Guy,
          Andrei_Sambra, Matt_Stone, Oliver_Terbu, Ken_Ebert,
          Dmitri_Zagidulin, Kaz_Ashimura, Ted_Thibodeau,
          Jonathan_Holt, Allen_Brown, Benjamin_Young, Joe_Andrieu,
          Brian_Ulicny, Kaliya_Young, Ned_Smith, Yancy_Ribbens

   Regrets
          David_Chadwick

   Chair
          Dan_Burnett, Matt_Stone

   Scribe
          dlongley, gannan

Contents

     * [3]Topics
         1. [4]Agenda review, Introductions, Re-introductions
         2. [5]PR review
         3. [6]Any other business?
     * [7]Summary of Action Items
     * [8]Summary of Resolutions
     __________________________________________________________

   <dlongley> scribenick: dlongley

Agenda review, Introductions, Re-introductions

   burn: We're going to start with reviewing PRs. Then we'll look
   at issues, we won't start with assigning names to issues and
   I'll give background on that in a moment. Anyone joining for
   the first time today?
   ... Manu would you like to reintroduce yourself?

   manu: Hi, I'm Manu Sporny. I work at Digital Bazaar. We've been
   involved in the VC stuff for quite a while, a number of our
   products utilize the tech. We work with large gov't, banking,
   finance, etc customers. Look forward to the spec reaching REC
   this year.

   burn: The chairs and editors have has some more conversations
   and we'd like to cover a few important points.
   ... The spec was published as CR last Thursday, yay!

   <manu> yaaay! to CR being published :))))

   burn: In addition, the group has been extended to the end of
   September, congratulations to everyone.

   <dmitriz> yayyyy!!!

   <manu> yaaay! for administrative Charter extension!!!!

   burn: This is what we were hoping for and it's confirmed now.
   ... At this stage, our groups work and the status of our spec
   is a little at risk. I will put this bluntly. It is at risk
   from two kinds of people. Those that wish the group to fail and
   those that believe that what they want is more important than
   having the group succeed.
   ... There are 4 ways this can manifest. 1. Trolling of the
   issues list. Intentionally or unintentionally splitting the
   group over some issue that's not worth destroying the spec
   over.
   ... 2. Trolling of our issues list by proposing unnecessary
   normative changes that would force us to have another CR.
   ... 3. Responding slowly to discussions or at the very last
   moment. Malicious responders will do this to make the group go
   past its charter time. It can also happen if the group loses
   focus.
   ... 4. Someone arguing that someone has not addressed the issue
   after the group has considered it and made a decision. That can
   happen sometimes but people who wish the group ill will tend to
   do this. We have some suspicion that there are people that do
   feel that way about the group.
   ... I'm going to go over some more about this. At this point a
   single normative change will require a new CR. To issue a new
   one we would need a successful publication vote near the end of
   May. We'd need wide review by the end of April.
   ... Here are the guidelines and rules that we plan to follow.
   Our goal is to not make any normative changes unless absolutely
   necessary. If we MUST then we need to make them right away. If
   there's something that really must happen, don't wait.
   ... For every issue, we will either request or propose
   non-normative spec changes if possible.
   ... The reason for this is to provide that we have indeed
   considered the issue. We will be going from a 14-day default
   close to a 7-day default close. I'm not happy about this but I
   think it's the way we'll have to go.
   ... It doesn't mean that if there is strong objection to the
   close and that person is on vacation we can't make exceptions.
   ... But in order to keep the work moving it's dangerous for 14
   days ... if you don't respond to close it because people might
   wait 14 days and then give a comment and then do it again and
   then we're over time.
   ... We will open a closed issue but only if new information is
   brought. This is appropriate at this stage, it is what CR
   means.
   ... Ok, thank you.
   ... Looking for a new scribe...

   <scribe> scribenick: gannan

PR review

   <manu> [9]https://github.com/w3c/vc-data-model/issues/492

      [9] https://github.com/w3c/vc-data-model/issues/492

   manu: We're going to reference the issues first and then talk
   about the PRs

   <burn>
   [10]https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&
   q=is%3Aissue+is%3Aopen+-label%3Adefer

     [10] https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is:issue+is:open+-label:defer

   <manu> [11]https://github.com/w3c/vc-data-model/pull/510

     [11] https://github.com/w3c/vc-data-model/pull/510

   manu: Tony Nadalin raised a concern that issues about private
   browsing mode in different browsers and he wanted to point out
   that each browser may or may not have private browsing mode
   ... Brent addressed the issue in his PR with a non-normative
   change
   ... Any objections? If not I will make a proposal.

   <manu> PROPOSED: Merge non-normative PR #510 in order to
   clarify private-browsing mode concerns raised in issue #492.

   <dlongley> +1

   burn: Focused on closing issues and minimizing discussion. We
   want to be clear with our resolutions so that they're entered
   into the minutes.

   <brent> +1

   <ken> +1

   <TallTed> +1

   <deiu> +1

   <tzviya> +1

   <stonematt> +1

   <burn> +1

   <oliver_terbu> +1

   <manu> +1

   manu: Ensure that only one representative from the company is
   adding a +1.

   TallTed: In a working group this is not the case, it is one
   person, one vote.

   <stonematt> +1 to call for objections in following resolutions

   burn: I would rather not do a vote and just call for
   objections.

   RESOLUTION: Merge non-normative PR #510 in order to clarify
   private-browsing mode concerns raised in issue #492.

   <manu> [12]https://github.com/w3c/vc-data-model/issues/493

     [12] https://github.com/w3c/vc-data-model/issues/493

   <manu> [13]https://github.com/w3c/vc-data-model/pull/499

     [13] https://github.com/w3c/vc-data-model/pull/499

   manu: Next PR has to do with security considerations section,
   issue 493. Tony is asserting that there are lowercase musts in
   a non-normative sections. Chaals created a PR with
   non-normative changes to address Tony's concerns. It changes
   text from "must" to "needs to"

   <manu> PROPOSED: Merge non-normative PR #499 in order to
   clarify that existing 'must' was not a normative statement,
   which was raised in issue #493. Close issue #493 after the
   merge.

   manu: any objections to that proposal?

   RESOLUTION: Merge non-normative PR #499 in order to clarify
   that existing 'must' was not a normative statement, which was
   raised in issue #493. Close issue #493 after the merge.

   <manu> [14]https://github.com/w3c/vc-data-model/issues/495

     [14] https://github.com/w3c/vc-data-model/issues/495

   manu: PR for token binding, issue 495

   <manu> [15]https://github.com/w3c/vc-data-model/pull/497

     [15] https://github.com/w3c/vc-data-model/pull/497

   manu: ... Tony is requesting we link to RFC ???, we have a PR
   that updates a link to the specification

   <manu> PROPOSED: Merge non-normative PR #497 in order to update
   to an informative reference to RFC8471 raised in issue #495.
   Close issue #495 once the PR is merged.

   manu: any objections?

   RESOLUTION: Merge non-normative PR #497 in order to update to
   an informative reference to RFC8471 raised in issue #495. Close
   issue #495 once the PR is merged.

   <manu> [16]https://github.com/w3c/vc-data-model/issues/482

     [16] https://github.com/w3c/vc-data-model/issues/482

   manu: Next item, issue 482. Tony asserts that the introduction
   is misleading because it talks about digital signatures...
   ... ...our specification doesn't standardize on proof formats

   <manu> PROPOSED: Add more clarifying text to the specification
   noting that while the specification does not standardize on
   signature format, the WG is aware of at least three mechanisms
   (JWTs, LD-Proofs, and ZKPs) that are capable of protecting the
   contents of the data model at the time of publication that are
   being used in deployments of the technology and expects those
   mechanisms to mature independently as well as new mechanisms to
   become standardized.

   manu: ...we would make a non normative clarification to the
   spec
   ... ...the spec already states that we are not choosing one
   signature mechanism, we are proof agnostic
   ... any objections?

   Justin_R: no objections, I think it is the right way to go. I
   want to make sure that the existing text does veer towards LD
   as the base model...
   ... ...and everything else is an expression of the LD model

   <jonathan_holt> 1+

   manu: can you suggest in the issue or in the PR some concrete
   non-normative spec changes?

   Justin_R: sure, could you tag me as a reviewer so I can look at
   it. To prevent stepping on each others toes.

   burn: Let's make sure we can do that.

   Justin_R: Or a comment.

   manu: Taking note of that.

   Justin_R: Thank you.

   manu: any objections?

   RESOLUTION: Add more clarifying text to the specification
   noting that while the specification does not standardize on
   signature format, the WG is aware of at least three mechanisms
   (JWTs, LD-Proofs, and ZKPs) that are capable of protecting the
   contents of the data model at the time of publication that are
   being used in deployments of the technology and expects those
   mechanisms to mature independently as well as new mechanisms to
   become standardized.

   <manu> [17]https://github.com/w3c/vc-data-model/issues/483

     [17] https://github.com/w3c/vc-data-model/issues/483

   manu: next, section 4.1 @context... issue 483
   ... ...tony has asserted that there is no reason to have a
   @context, it should be removed or made optional
   ... ...there has been a lot of discussion around interop
   between json only and json-ld processors
   ... ...we've been discussing this for a long time and the
   points that Tony raised has been discussed by the working group
   ... ...the working group made a vote to make @context mandatory
   in our f2f meeting with broad agreement
   ... ...you do not need to process @context when using a JSON
   only processor

   <manu> PROPOSED: The VCWG had considered all points raised by
   issue #483 throughout the lifetime of the WG's operation, no
   new information was provided by issue #483 to convince the WG
   to change @context being mandatory (which has broad support in
   the WG with no objections), and thus the issue should be closed
   with no changes to the specification.

   manu: any objections?

   jonathan_holt: It goes into the mime-type discussion we had in
   Barcelona, we should require @context

   manu: To be clear you are saying that this is part of the
   conversation, you are not rejecting the proposal
   ... that is a formal objection, we are requiring @context

   <dlongley> the `@context` is on the `vc` .. not on the JWT. ...
   is this a clarification we need?

   jonathan_holt: we should be specific on when @context is
   required

   manu: we need some spec text

   jonathan_holt: I'll bubble up my issue

   <Zakim> brent, you wanted to say text clarification that
   explicitly points out that if the data model is encoded as a
   JWT, no processing of the @context is expected may be helpful

   burn: It might be more efficient to have a conversation

   brent: I think it we added some text that clarifies if the data
   model is processed as a JWT then no processing of @context is
   needed
   ... @context needs to be present but need not be processed by
   their processor

   manu: we can't proceed... need to have a conversation with
   jonathan_holt... brent go ahead and write a PR with this issue
   and potentially others

   TallTed: what I'm seeing in this issue thread, is not an issue
   about processing the @context content. It's about someone
   working exclusively with JWT's and do not want to have @context
   in their credential and they have no care for JSON-LD

   manu: It's necessary for the data encapsulated in the JWTs, if
   it's not in the VC then it's semantically ambiguous

   TallTed: That needs to be addressed

   manu: That is addressed in issue 491

   <dlongley> +1 it's not about JWT, it's about the payload IN the
   JWT.

   TallTed: We need to address what others that don't understand,
   @context should be in the payload in the JWT

   manu: We'll refer to this in the issue

   Justin_R: It sounds like that fundamentally a VC is JSON-LD doc
   with many types of expression
   ... ... if that's the case then we need to be explicit, if not
   then these issues do have merit

   manu: It's not just a JSON-LD document, it's a hybrid. We have
   something that could just use JSON processing or JSON-LD
   processing

   <manu> [18]https://github.com/w3c/vc-data-model/issues/494

     [18] https://github.com/w3c/vc-data-model/issues/494

   manu: this needs more discussion
   ... In the next issue, has to do with content integrity
   ... Tony says there is no need to have content integrity in
   JWTs
   ... This is talking about links in documents, we warn that
   outgoing links need content integrity, JWTs do not solve that
   problem

   <manu> PROPOSED: The content-integrity section of the
   specification describes how outgoing links from a document may
   be protected. Issue #494 asserts that JWTs provide
   content-integrity protection for outgoing links, which is
   false.The VCWG is also supportive of the use of @context as a
   core part of the data model. Issue #494 should be closed with
   no changes to the specification.

   manu: Basically, no change to the spec. It's a non-normative
   section, we are not saying you need to have content integrity
   for outgoing links but recommend a few mechanisms to achieve
   this
   ... any objections?

   RESOLUTION: The content-integrity section of the specification
   describes how outgoing links from a document may be protected.
   Issue #494 asserts that JWTs provide content-integrity
   protection for outgoing links, which is false.The VCWG is also
   supportive of the use of @context as a core part of the data
   model. Issue #494 should be closed with no changes to the
   specification.

   <manu> [19]https://github.com/w3c/vc-data-model/issues/498

     [19] https://github.com/w3c/vc-data-model/issues/498

   manu: next is issue 498, Tony says that there are no
   interoperable parts of the spec that makes it verifiable

   <TallTed> TallTed: "JWTs provide content-integrity protection
   for outgoing links" = true. "JWTs provide content-integrity
   protection for content of outgoing links" = false.

   manu: ...remove verifiable from the spec and make JWTs the
   normative way of expressing credentials
   ... ...the issue is about the title of the specification and
   removing the word verifiable

   <manu> PROPOSED: The specification clearly defines the meaning
   of "verifiable credential" and the VCWG has spent a
   considerable amount of time discussing and running surveys on
   the proper name for the specification. The VCWG believes the
   name of the specification is appropriate. Issue #498 should be
   closed with no change to the title of the specification.

   manu: ...the group has had a long discussion and agreed that it
   should be the "Verifiable Credentials" data model
   ... any objections?

   RESOLUTION: The specification clearly defines the meaning of
   "verifiable credential" and the VCWG has spent a considerable
   amount of time discussing and running surveys on the proper
   name for the specification. The VCWG believes the name of the
   specification is appropriate. Issue #498 should be closed with
   no change to the title of the specification.

   <dlongley> [20]https://github.com/w3c/vc-data-model/issues/502

     [20] https://github.com/w3c/vc-data-model/issues/502

   manu: next is a charter comment. Tony is mentioning that the
   web-authn should have been a liason in the charter. He wants to
   have a charter update. We just got a charter extension so we
   can't change the charter. Tony is the co-chair of the group and
   has made a full review of the specification already. The Web
   Authn group has the ability to do any additional reviews

   burn: we are not changing the charter
   ... we do not need a formal liason relationship for comments to
   be made on the specification

   <manu> PROPOSED: The VCWG notes that the charter cannot be
   changed at present and thus new Liaison relationships cannot be
   added. The VCWG also notes and is thankful of the review of the
   specification that has been performed by Tony Nadalin, who is a
   co-chair of the WebAuthn WG, and welcomes comments from all
   interested Working Groups. Issue #513 should be closed with no
   change to the specification.

   manu: this is the new re-worked proposal?

   burn: any objections?

   RESOLUTION: The VCWG notes that the charter cannot be changed
   at present and thus new Liaison relationships cannot be added.
   The VCWG also notes and is thankful of the review of the
   specification that has been performed by Tony Nadalin, who is a
   co-chair of the WebAuthn WG, and welcomes comments from all
   interested Working Groups. Issue #513 should be closed with no
   change to the specification.

   <manu> [21]https://github.com/w3c/vc-data-model/issues/513

     [21] https://github.com/w3c/vc-data-model/issues/513

   kaz: The first two proposals should be removed from the minutes
   later because they're overridden by the third proposal

   manu: correct

   (Originally there were three proposals made during the call,
   but the first two proposals have been removed and only the
   final proposal confirmed is recorded above)

   manu: Tony says that JWKs should be listed as a normative
   reference, brent and oliver had a back and forth in the
   comments. It seems that JWKs are not listed

   <manu> PROPOSED: Add non-normative text to the specification
   that makes an informative reference to the JWK specification
   and notes that key discovery can be performed in a variety of
   ways including the use of JWK and DID-based key discovery.

   manu: ...the suggestion is to make a non-normative spec change
   that points to JWK as a way to describe keys but not the only
   way
   ... any objections to that proposal?

   <Justin_R> +1 informative references to examples are good

   <Justin_R> (I had raised this previously)

   RESOLUTION: Add non-normative text to the specification that
   makes an informative reference to the JWK specification and
   notes that key discovery can be performed in a variety of ways
   including the use of JWK and DID-based key discovery.

   <Justin_R> np

   <manu> [22]https://github.com/w3c/vc-data-model/issues/490

     [22] https://github.com/w3c/vc-data-model/issues/490

   Justin_R: going to tag you in the resolution, since you had
   some concerns

   manu: issue 490, this is about the Trust Model. Section 5.2
   which is non-normative. We talk about what the Trust Model
   should be, it's not the only one
   ... tony suggests that this should be put at-risk, I've seen no
   spec that has put non-normative text as at-risk
   ... nothing in this section has implementation burden so
   there's no reason to mark it at risk

   <manu> PROPOSED: Section 5.2: Trust Model is a non-normative
   section on the specification. Issue #490 asserts that it should
   be marked at risk. Non-normative sections contain no normative
   statements and thus are not at risk during or after the
   Candidate Recommendation phase. Issue #490 should be closed
   with no changes to the specification.

   manu: it's a no change to the specification

   <TallTed> +1 non-normative, so no implementation expected, so
   can't be at-risk

   burn: at risk as I understood it during my 20years, at risk
   means at risk from removal from the specification due to
   insufficient implementation

   kaz: just want to confirm that the feature we're discussing
   wouldn't impact implementations

   (burn agrees that is a good point, and doesn't think it would
   impact implementations)

   manu: any objections?

   RESOLUTION: Section 5.2: Trust Model is a non-normative section
   on the specification. Issue #490 asserts that it should be
   marked at risk. Non-normative sections contain no normative
   statements and thus are not at risk during or after the
   Candidate Recommendation phase. Issue #490 should be closed
   with no changes to the specification.

   manu: do the chairs want to wrap up or process one more issue?

   burn: it'd be good to wrap up

Any other business?

   Kaliya mentions she and Heather have published a book which has
   a chapter on Verifiable Credentials

   burn: any questions or comments before we end the call?

   yancy: just wanted to say I raised a few issues on the test
   suite, would like some responses

   burn: we need to discuss this, test could change because they
   were implemented incorrectly or there was an update to
   normative references

   dmitriz: can we work on it next call?

   burn: would prefer to continue it offline
   ... to short notice, but the chairs can talk about a way too
   have more working calls between our meetings
   ... thank you everyone, bye

Summary of Action Items

Summary of Resolutions

    1. [23]Merge non-normative PR #510 in order to clarify
       private-browsing mode concerns raised in issue #492.
    2. [24]Merge non-normative PR #499 in order to clarify that
       existing 'must' was not a normative statement, which was
       raised in issue #493. Close issue #493 after the merge.
    3. [25]Merge non-normative PR #497 in order to update to an
       informative reference to RFC8471 raised in issue #495.
       Close issue #495 once the PR is merged.
    4. [26]Add more clarifying text to the specification noting
       that while the specification does not standardize on
       signature format, the WG is aware of at least three
       mechanisms (JWTs, LD-Proofs, and ZKPs) that are capable of
       protecting the contents of the data model at the time of
       publication that are being used in deployments of the
       technology and expects those mechanisms to mature
       independently as well as new mechanisms to become
       standardized.
    5. [27]The content-integrity section of the specification
       describes how outgoing links from a document may be
       protected. Issue #494 asserts that JWTs provide
       content-integrity protection for outgoing links, which is
       false.The VCWG is also supportive of the use of @context as
       a core part of the data model. Issue #494 should be closed
       with no changes to the specification.
    6. [28]The specification clearly defines the meaning of
       "verifiable credential" and the VCWG has spent a
       considerable amount of time discussing and running surveys
       on the proper name for the specification. The VCWG believes
       the name of the specification is appropriate. Issue #498
       should be closed with no change to the title of the
       specification.
    7. [29]The VCWG notes that the charter cannot be changed at
       present and thus new Liaison relationships cannot be added.
       The VCWG also notes and is thankful of the review of the
       specification that has been performed by Tony Nadalin, who
       is a co-chair of the WebAuthn WG, and welcomes comments
       from all interested Working Groups. Issue #513 should be
       closed with no change to the specification.
    8. [30]Add non-normative text to the specification that makes
       an informative reference to the JWK specification and notes
       that key discovery can be performed in a variety of ways
       including the use of JWK and DID-based key discovery.
    9. [31]Section 5.2: Trust Model is a non-normative section on
       the specification. Issue #490 asserts that it should be
       marked at risk. Non-normative sections contain no normative
       statements and thus are not at risk during or after the
       Candidate Recommendation phase. Issue #490 should be closed
       with no changes to the specification.

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [32]scribe.perl version 1.154 ([33]CVS log)
    $Date: 2019/04/07 15:41:39 $

     [32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [33] http://dev.w3.org/cvsweb/2002/scribe/
Received on Sunday, 7 April 2019 15:44:52 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 7 April 2019 15:44:52 UTC