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

Minutes for VCWG telecon 16 April 2019

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Wed, 17 Apr 2019 02:25:23 +0900
Message-ID: <CAJ8iq9VyNSHQ-d-+eBeGTmXiNTueQo5358zA0q=Uxz9Ok-Dvpw@mail.gmail.com>
To: public-vc-wg@w3.org
available at:
  https://www.w3.org/2019/04/16-vcwg-minutes.html

also as text below.

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

Kazuyuki

---

   [1]W3C

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

                               - DRAFT -

                    Verifiable Claims Working Group

16 Apr 2019

   [2]Agenda

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

Attendees

   Present
          Amy_Guy, Brent_Zundel, Dan_Burnett, Dave_Longley,
          David_Chadwick, Ganesh_Annan, Jonathan_Holt,
          Justin_Richer, Kaliya_Young, Kaz_Ashimura, Ken_Ebert,
          Manu_Sporny, Matt_Stone, Nick_Carroll, Sercan_Kum,
          Ted_Thibodeau, Yancy_Ribbens, Oliver_Terbu,
          Nathan_George

   Regrets
          Andrei_Samba

   Chair
          Dan_Burnett, Matt_Stone

   Scribe
          TallTed

Contents

     * [3]Topics
         1. [4]plan/agenda
         2. [5]PR announcements
         3. [6]Issue lightning round: close the issues we can
     * [7]Summary of Action Items
     * [8]Summary of Resolutions
     __________________________________________________________

   <burn> scribenick: TallTed

plan/agenda

   burn: we'll start with PR announcements (mostly not
   decision-making), and move into an "issue lightning round" to
   quickly close what we can
   ... not to run over disagreements -- discussion can be
   scheduled for another call
   ... proposing increasing call duration to 2 hours

   burn: with a shift to start 1 hour earlier

   <manu> +1 to starting call 1 hour earlier.

   <stonematt> +1 to starting earlier

   <manu> also, fwiw -- +1 to running call for extra hour today.

   <jonathan_holt> +1 but starting next week

   <DavidC> +1

   <dlongley> +1 fine with doing it this week

   <jonathan_holt> I don't want to miss the CCG meeting

   <ken> -1 for today

   <Zakim> manu, you wanted to ask about overlap?

   <ken> +1 starting next week

   <manu> current CCG agenda - TL;DR: EOY Survey Results, cont'd
   and Code of Conduct and Conflict Management (if time permits)

PR announcements

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

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

   manu: we have an increasing backlog, including 5 large PRs from
   grant noble
   ... these will cause merge conflicts with every other PR ...
   which will need to be fixed ASAP

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

     [10] https://github.com/w3c/vc-data-model/pull/539

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

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

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

     [12] https://github.com/w3c/vc-data-model/pull/542

   manu: generally in good shape -- ready to merge or discussion
   is ongoing

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

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

   manu: asserting that PR#542 is a bug-fix to normative text

   [ no objections to assertion ]

   manu: any other concerns on PRs? need extra call time for any
   PR?

   [ silence ]

Issue lightning round: close the issues we can

   <Justin_R> @manu -- I looked just now and there was one line
   that I'd missed from your comments (it was right next to
   another line that was fixed and I missed the repeated term).

   <Justin_R> Everything else is in there though so please review

   <Justin_R> This is for #539

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

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

   manu: these are all proposals; primarily looking for objections

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

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

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

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

   manu: issue suggests using a JWK (seems really to mean JWT) as
   a VC
   ... WG has clarified that a JWT is not a VC, but a JWT can be
   used to secure a VC

   manu: language around context processing is being clarified

   <manu> PROPOSED: A JWT is not a Verifiable Credential as the
   data models differ. A JWT can be used to secure a Verifiable
   Credential as described in Section 6.3.1. The language related
   to @context processing for JWT-based processors should be
   clarified to note that dereferencing @context values is not
   required, which is a non-substantive clarification to the
   existing text in the specification. The IANA registration for
   the vc and vp JWT claims should be separated into an IANA
   Considerations section. Issue #520 should be closed after the
   PR is merged.

   [ no objections ]

   RESOLUTION: A JWT is not a Verifiable Credential as the data
   models differ. A JWT can be used to secure a Verifiable
   Credential as described in Section 6.3.1. The language related
   to @context processing for JWT-based processors should be
   clarified to note that dereferencing @context values is not
   required, which is a non-substantive clarification to the
   existing text in the specification. The IANA registration for
   the vc and vp JWT claims should be separated into an IANA
   Considerations section. Issue #520 should be closed after the
   PR is merged.

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

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

   <manu> PROPOSED: One of the goals of the Verifiable Credentials
   Data Model specification is to define extensibility points in
   the data model and achieve interoperability on the
   extensibility points (not the extensions themselves). The
   interoperability tests will focus on ensuring that the minimum
   information exists in extensions to identify the extension
   without needing to define each extension in detail for this
   iteration of the Working Group. Defining extensions to the base
   data model is outside of the scope of the WG's charter. All
   features that the Working Group deems at risk were marked
   before entering CR. No new at-risk features have been
   identified after processing issue #523, which should be closed
   with no changes to the specification.

   [ no objections ]

   RESOLUTION: One of the goals of the Verifiable Credentials Data
   Model specification is to define extensibility points in the
   data model and achieve interoperability on the extensibility
   points (not the extensions themselves). The interoperability
   tests will focus on ensuring that the minimum information
   exists in extensions to identify the extension without needing
   to define each extension in detail for this iteration of the
   Working Group. Defining extensions to the base data model is
   outside of the scope of the WG's charter. All features that the
   Working Group deems at risk were marked before entering CR. No
   new at-risk features have been identified after processing
   issue #523, which should be closed with no changes to the
   specification.

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

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

   <manu> PROPOSED: The VCWG seeks to demonstrate interoperability
   at the data model and extension points in the specification,
   not the extensions themselves as the group is not chartered to
   work on extensions. The VCWG has reviewed all conformance
   statements, has implemented a test suite that tests all
   required conformance statements in the specification, and
   asserts that this approach is appropriate for a data model
   specification. Section 5.3 should be marked as

   <manu> non-normative as it does not contain any normative
   statements. Section 5.3.1 should remain normative. These are
   non-substantive changes and once they are made, issue #524
   should be closed.

   scribenick: dlongley

   TallTed: Section 5.3 cannot be non-normative if Section 5.3.1
   is normative. You can't have a non-normative section with
   normative subsections.

   burn: You can do it the other way around though.

   manu: I defer to you, Ted. I thought you could have massive
   non-normative sections and mark subsections as normative.

   <rhiaro> Logically what Ted says makes sense to me

   <brent> +1 to TallTed

   TallTed: I don't believe so. Unless you have huge red flags at
   the top that say there's some tiny section that is normative.
   ... But that doesn't really work out.

   <dlongley> manu writes up a new proposal

   <burn> Ted is right. Implementers read 'non-normative' at the
   top and ignore the contents. The reverse is okay, labeling
   normative at the top and having subsections be non-normative

   <burn> The end result is the same either way, just better
   understood

   TallTed: To be clear, it is fine to put into each of the other
   subsections that it is non-normative.

   manu: But that's not the case we have here, it's the opposite.

   TallTed: It's not ok to have 5.3 non-normative and 5.3.1 as
   normative, but we can individually label subsections as
   non-normative. 5.3 normative, 5.3.1 normative, 5.3.2
   non-normative, 5.3.3 non-normative, etc -- it just needs to be
   labeled individually.

   <Justin_R> +1 to Tall_Ted's suggestion

   burn: Let's take this offline. Ted is correct, but the end
   result is the same as what you want. You can't have a normative
   within a non-normative.

   <manu> PROPOSED: The VCWG seeks to demonstrate interoperability
   at the data model and extension points in the specification,
   not the extensions themselves as the group is not chartered to
   work on extensions. The VCWG has reviewed all conformance
   statements, has implemented a test suite that tests all
   required conformance statements in the specification, and
   asserts that this approach is appropriate for a data model
   specification. Section 5.3 should remain normative as it
   contains a normative section 5.3.1. Section 5.3.1 should remain
   normative. Other PRs are in process that clarify the findings
   of this proposal and once they are made, issue #524 should be
   closed.

   manu: There are no sections 5.3.2+.

   <kaz> [19]section 5.3

     [19] https://w3c.github.io/vc-data-model/#extensibility

   scribenick: TallTed

   [ no objections ]

   RESOLUTION: The VCWG seeks to demonstrate interoperability at
   the data model and extension points in the specification, not
   the extensions themselves as the group is not chartered to work
   on extensions. The VCWG has reviewed all conformance
   statements, has implemented a test suite that tests all
   required conformance statements in the specification, and
   asserts that this approach is appropriate for a data model
   specification. Section 5.3 should remain normative as it
   contains a normative section 5.3.1. Section 5.3.1 should remain
   normative. Other PRs are in process that clarify the findings
   of this proposal and once they are made, issue #524 should be
   closed.

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

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

   <manu> PROPOSED: Non-normatively elaborate on the JSON
   Verifiable Credential processor rule that ensures that the
   array of values associated with @context should be in the
   expected order for the processor. Close issue #525 after the PR
   has been merged.

   <manu> PROPOSED: Editors will non-normatively elaborate on the
   rules that ensure that the array of values associated with
   @context should be in the expected order. Close issue #525
   after the PR has been merged.

   [ no objection ]

   RESOLUTION: Editors will non-normatively elaborate on the rules
   that ensure that the array of values associated with @context
   should be in the expected order. Close issue #525 after the PR
   has been merged.

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

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

   <manu> PROPOSED: Multiple non-normative commits and PRs (#475,
   #499) have been written, reviewed and applied for this issue.
   The WG does not believe that any more mis-characterized
   normative terminology appears in non-normative sections. Issue
   #394 should be closed.

   [ no objection ]

   RESOLUTION: Multiple non-normative commits and PRs (#475, #499)
   have been written, reviewed and applied for this issue. The WG
   does not believe that any more mis-characterized normative
   terminology appears in non-normative sections. Issue #394
   should be closed.

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

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

   <manu> PROPOSED: Issue #462 is addressed by PR #503, which
   makes non-normative changes detailing type information stored
   in a credential as requested by the reviewer. The PR has been
   approved by multiple parties and has been merged. Issue #462
   should be closed.

   [ no objection ]

   RESOLUTION: Issue #462 is addressed by PR #503, which makes
   non-normative changes detailing type information stored in a
   credential as requested by the reviewer. The PR has been
   approved by multiple parties and has been merged. Issue #462
   should be closed.

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

     [23] https://github.com/w3c/vc-data-model/issues/463

   <manu> PROPOSED: Issue #463 is addressed by PR #504, which
   makes non-normative changes to updated the definition of an
   entity requested by the reviewer. The PR has been approved by
   multiple parties and has been merged. Issue #463 should be
   closed.

   [ no objection ]

   RESOLUTION: Issue #463 is addressed by PR #504, which makes
   non-normative changes to updated the definition of an entity
   requested by the reviewer. The PR has been approved by multiple
   parties and has been merged. Issue #463 should be closed.

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

     [24] https://github.com/w3c/vc-data-model/issues/464

   <manu> PROPOSED: Issue #464 is addressed by PR #512, which
   makes non-normative changes related to the subject of the
   credential as requested by the reviewer. The PR has been
   approved by multiple parties and has been merged. Issue #464
   should be closed.

   [ no objection ]

   RESOLUTION: Issue #464 is addressed by PR #512, which makes
   non-normative changes related to the subject of the credential
   as requested by the reviewer. The PR has been approved by
   multiple parties and has been merged. Issue #464 should be
   closed.

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

     [25] https://github.com/w3c/vc-data-model/issues/466

   <manu> PROPOSED: Issue #466 is addressed by PR #477, which
   makes minor non-normative changes by changing "might perform"
   to "performs" for certain roles as requested by the reviewer.
   The PR has been approved by multiple parties and has been
   merged. Issue #466 should be closed.

   [ no objection ]

   RESOLUTION: Issue #466 is addressed by PR #477, which makes
   minor non-normative changes by changing "might perform" to
   "performs" for certain roles as requested by the reviewer. The
   PR has been approved by multiple parties and has been merged.
   Issue #466 should be closed.

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

     [26] https://github.com/w3c/vc-data-model/issues/471

   <manu> PROPOSED: Issue #471 is addressed by PR #507, which
   makes non-normative changes pointing out that trust is
   bilateral between issuers and verifiers as requested by the
   reviewer. The PR has been approved by multiple parties
   (including the reviewer), and has been merged. Issue #471
   should be closed.

   [ no objection ]

   RESOLUTION: Issue #471 is addressed by PR #507, which makes
   non-normative changes pointing out that trust is bilateral
   between issuers and verifiers as requested by the reviewer. The
   PR has been approved by multiple parties (including the
   reviewer), and has been merged. Issue #471 should be closed.

   <inserted> (burn suggest we extend the VCWG call today by 15
   mins at max to finish out the issue list)

   <TallTed> +1 finish out the list

   <stonematt> +1 to finish the list

   <dlongley> +1 to finish the list

   <brent> +1 to continuing the VCWG call

   <manu> +1, let's go finish the list! :)

   <SercanK> +1 finish the list

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

     [27] https://github.com/w3c/vc-data-model/issues/472

   <manu> PROPOSED: Issue #472 is addressed by PR #476, which
   makes non-normative changes noting that consent isn't implied
   by signatures on presentations as requested by the reviewer.
   The PR has been approved by multiple parties and has been
   merged. Issue #472 should be closed.

   [ no objection ]

   RESOLUTION: Issue #472 is addressed by PR #476, which makes
   non-normative changes noting that consent isn't implied by
   signatures on presentations as requested by the reviewer. The
   PR has been approved by multiple parties and has been merged.
   Issue #472 should be closed.

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

     [28] https://github.com/w3c/vc-data-model/issues/481

   <manu> PROPOSED: Issue #481 is addressed by PR #508 and PR
   #509, which make multiple non-normative changes to the
   definitions of roles in the ecosystem as requested by the
   reviewer. The PR has been approved by multiple parties and have
   been merged. Issue #481 should be closed.

   [ no objection ]

   RESOLUTION: Issue #481 is addressed by PR #508 and PR #509,
   which make multiple non-normative changes to the definitions of
   roles in the ecosystem as requested by the reviewer. The PR has
   been approved by multiple parties and have been merged. Issue
   #481 should be closed.

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

     [29] https://github.com/w3c/vc-data-model/issues/485

   <manu> PROPOSED: Issue #485 is addressed by PR #519, which
   makes non-normative changes noting that a JWK can also be used
   in the place of an `issuer` property as requested by the
   reviewer. The PR has been approved by multiple parties and has
   been merged. Issue #485 should be closed.

   [ no objection ]

   RESOLUTION: Issue #485 is addressed by PR #519, which makes
   non-normative changes noting that a JWK can also be used in the
   place of an `issuer` property as requested by the reviewer. The
   PR has been approved by multiple parties and has been merged.
   Issue #485 should be closed.

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

     [30] https://github.com/w3c/vc-data-model/issues/541

   <manu> PROPOSED: Issue #541 is addressed by PR #542, which
   makes a non-substantive change that fixes a bug in the
   specification related to JWT jti/sub values being swapped. This
   is a non-substantive change because there were two conflicting
   normative statements in the specification, the examples were
   clearly the intent, and any reasonable implementer would have
   implemented the feature correctly based on the existing JWT
   encoding rules in the specification. The PR has been approved
   by multiple parties as a non-substantive change and should be
   merged. Issue #541 should be closed after the PR is merged.

   [ no objection ]

   RESOLUTION: Issue #541 is addressed by PR #542, which makes a
   non-substantive change that fixes a bug in the specification
   related to JWT jti/sub values being swapped. This is a
   non-substantive change because there were two conflicting
   normative statements in the specification, the examples were
   clearly the intent, and any reasonable implementer would have
   implemented the feature correctly based on the existing JWT
   encoding rules in the specification. The PR has been approved
   by multiple parties as a non-substantive change and should be
   merged. Issue #541 should be closed after the PR is merged.

   manu: that ends the list of issues with pending PRs ...

   <stonematt> thank you, thank you, thank you to everyone!

   <dlongley> +1

   <DavidC> I will also be away next week so I might not be able
   to attend either

   burn: manu will be on vacation for the next week, so we expect
   not to process spec issues next week; instead, focus on the
   implementation guide and registry
   ... please do continue offline work on issues (outside of
   calls)

   adjourned

Summary of Action Items

Summary of Resolutions

    1. [31]A JWT is not a Verifiable Credential as the data models
       differ. A JWT can be used to secure a Verifiable Credential
       as described in Section 6.3.1. The language related to
       @context processing for JWT-based processors should be
       clarified to note that dereferencing @context values is not
       required, which is a non-substantive clarification to the
       existing text in the specification. The IANA registration
       for the vc and vp JWT claims should be separated into an
       IANA Considerations section. Issue #520 should be closed
       after the PR is merged.
    2. [32]One of the goals of the Verifiable Credentials Data
       Model specification is to define extensibility points in
       the data model and achieve interoperability on the
       extensibility points (not the extensions themselves). The
       interoperability tests will focus on ensuring that the
       minimum information exists in extensions to identify the
       extension without needing to define each extension in
       detail for this iteration of the Working Group. Defining
       extensions to the base data model is outside of the scope
       of the WG's charter. All features that the Working Group
       deems at risk were marked before entering CR. No new
       at-risk features have been identified after processing
       issue #523, which should be closed with no changes to the
       specification.
    3. [33]The VCWG seeks to demonstrate interoperability at the
       data model and extension points in the specification, not
       the extensions themselves as the group is not chartered to
       work on extensions. The VCWG has reviewed all conformance
       statements, has implemented a test suite that tests all
       required conformance statements in the specification, and
       asserts that this approach is appropriate for a data model
       specification. Section 5.3 should remain normative as it
       contains a normative section 5.3.1. Section 5.3.1 should
       remain normative. Other PRs are in process that clarify the
       findings of this proposal and once they are made, issue
       #524 should be closed.
    4. [34]Editors will non-normatively elaborate on the rules
       that ensure that the array of values associated with
       @context should be in the expected order. Close issue #525
       after the PR has been merged.
    5. [35]Multiple non-normative commits and PRs (#475, #499)
       have been written, reviewed and applied for this issue. The
       WG does not believe that any more mis-characterized
       normative terminology appears in non-normative sections.
       Issue #394 should be closed.
    6. [36]Issue #462 is addressed by PR #503, which makes
       non-normative changes detailing type information stored in
       a credential as requested by the reviewer. The PR has been
       approved by multiple parties and has been merged. Issue
       #462 should be closed.
    7. [37]Issue #463 is addressed by PR #504, which makes
       non-normative changes to updated the definition of an
       entity requested by the reviewer. The PR has been approved
       by multiple parties and has been merged. Issue #463 should
       be closed.
    8. [38]Issue #464 is addressed by PR #512, which makes
       non-normative changes related to the subject of the
       credential as requested by the reviewer. The PR has been
       approved by multiple parties and has been merged. Issue
       #464 should be closed.
    9. [39]Issue #466 is addressed by PR #477, which makes minor
       non-normative changes by changing "might perform" to
       "performs" for certain roles as requested by the reviewer.
       The PR has been approved by multiple parties and has been
       merged. Issue #466 should be closed.
   10. [40]Issue #471 is addressed by PR #507, which makes
       non-normative changes pointing out that trust is bilateral
       between issuers and verifiers as requested by the reviewer.
       The PR has been approved by multiple parties (including the
       reviewer), and has been merged. Issue #471 should be
       closed.
   11. [41]Issue #472 is addressed by PR #476, which makes
       non-normative changes noting that consent isn't implied by
       signatures on presentations as requested by the reviewer.
       The PR has been approved by multiple parties and has been
       merged. Issue #472 should be closed.
   12. [42]Issue #481 is addressed by PR #508 and PR #509, which
       make multiple non-normative changes to the definitions of
       roles in the ecosystem as requested by the reviewer. The PR
       has been approved by multiple parties and have been merged.
       Issue #481 should be closed.
   13. [43]Issue #485 is addressed by PR #519, which makes
       non-normative changes noting that a JWK can also be used in
       the place of an `issuer` property as requested by the
       reviewer. The PR has been approved by multiple parties and
       has been merged. Issue #485 should be closed.
   14. [44]Issue #541 is addressed by PR #542, which makes a
       non-substantive change that fixes a bug in the
       specification related to JWT jti/sub values being swapped.
       This is a non-substantive change because there were two
       conflicting normative statements in the specification, the
       examples were clearly the intent, and any reasonable
       implementer would have implemented the feature correctly
       based on the existing JWT encoding rules in the
       specification. The PR has been approved by multiple parties
       as a non-substantive change and should be merged. Issue
       #541 should be closed after the PR is merged.

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [45]scribe.perl version 1.154 ([46]CVS log)
    $Date: 2019/04/16 17:24:24 $

     [45] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [46] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 16 April 2019 17:26:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 April 2019 17:26:31 UTC