Minutes for VCWG telecon 7 May 2019

available at:
  https://www.w3.org/2019/05/07-vcwg-minutes.html

also as text below.

Thanks a lot for taking these minutes, David!

Kazuyuki

---

   [1]W3C

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

                               - DRAFT -

                    Verifiable Claims Working Group

07 May 2019

   [2]Agenda

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

Attendees

   Present
          Dan_Burnett, Ted_Thibodeau, Manu_Sporny, David_Chadwick,
          Dmitri_Zagidulin, Brent_Zundel, Yancy_Ribbens,
          Ken_Ebert, Allen_Brown, Andrei_Sambra, Jonathan_Holt,
          Sercan_Kum, Kaz_Ashimura, Amy_Guy, Justin_Richer

   Regrets
          Tzviya_Siegman

   Chair
          Dan

   Scribe
          DavidC

Contents

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

   <burn> Chair: Dan_Burnett, Matt_Stone

   <manu> scribenick: DavidC

   <scribe> Agenda: PRs

PR announcements

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

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

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

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

   manu: This PR is stuck until we get comments from other people

   Please can people review this PR and comment on it

   TallTed asks if anyone else has looked at this?

   No-one appears to except Manu

   <manu> DavidC: We are getting in too deep with this, other than
   order is approximate. We don't wnat to give a specific menu for
   the order, or specific flow diagram, I don't think we need to
   be specific here.

   <burn> DavidC: we are going too deep with this. All we need is
   the approx. order. We don't want a detailed order here.

   Ken will do a review

   <manu> TallTed: There are other sections that prevent things
   from happening, that's specific, if this is not important, then
   none should be there.

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

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

   @context will be added to the Appendix.

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

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

   manu: This announces the end of the CR period

   burn: The end of the comment period means that external reviews
   may not be processed
   ... This is so that a specification can end (otherwise people
   may comment on it for ever)

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

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

   burn: Group members are not included in this, as they are
   working hard to make sure the spec is finished

   scribenick: manu

   DavidC: Yes, I was asking you to add text to my text.
   ... If people want to know exactly about the @context, then
   they can go read another spec... I think we need to do an
   intro.
   ... There needs to be a minimum, there is some minimum
   irreducible features... that's what I'm looking for.

   <dmitriz> "how to extend a VC" / create your own context — that
   sounds like it needs a section (or its own guide) in the
   Implementation Guide

   <burn> Note that long conversation between manu and davidc was
   not scribed

   scribenick: burn

   manu: using VCs does not require JSON-LD knowledge, but
   extending VCs requires a deep knowledge of JSON-LD

   davidc: we need to know what each field is for, and we will
   have to add fields.
   ... reasonably happy with schema def, but not schema.org
   because it doesn't say what must/may be present.

   <brent> the minimum irreducible set of requirements for context
   for JSON and JSON-LD is that the context must be present

   davidc: context is a big vague hole.

   manu: let's work on this in the PR

   scribenick: DavidC

   PR #601 is adding missing presentation types

Issue lightning round: close the issues we can

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

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

   Manu: this says to use JSON-LD 1.0 and not 1.1
   ... we need to get 1.1 to CR so that it can be referenced
   ... but currently we will have to reference 1.0

   <manu> PROPOSAL: Issue #537 should be addressed by referencing
   JSON-LD 1.1 instead of JSON-LD 1.0. This is a non-substantive
   change since the Verifiable Credentials Data Model
   specification included JSON-LD 1.1 features inline for JSON-LD
   based processors and thus implementers would not have to change
   their implementations as a result of the updated reference.
   Issue #537 should be closed after the PR is merged.

   Manu: we use the protected mechanism to stop terms being
   redefined in JSON-LD
   ... instead we require @context values to be placed in order

   <TallTed> +1

   <ken> +1

   <burn> +1

   <deiu> +1

   RESOLUTION: Issue #537 should be addressed by referencing
   JSON-LD 1.1 instead of JSON-LD 1.0. This is a non-substantive
   change since the Verifiable Credentials Data Model
   specification included JSON-LD 1.1 features inline for JSON-LD
   based processors and thus implementers would not have to change
   their implementations as a result of the updated reference.
   Issue #537 should be closed after the PR is merged.

   <brent> burn: I see no objections

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

     [15] https://github.com/w3c/vc-data-model/issues/551

   <manu> PROPOSAL: Issue #551 is addressed by PR #563 which makes
   non-normative changes to fix the missing @context values in a
   number of the examples in the appendix. Issue #551 should be
   closed.

   <ken> +1

   <TallTed> +1

   <DavidC> +1

   RESOLUTION: Issue #551 is addressed by PR #563 which makes
   non-normative changes to fix the missing @context values in a
   number of the examples in the appendix. Issue #551 should be
   closed.

   <brent> burn: no objections

   <manu>
   [16]https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&
   q=is%3Aissue+is%3Aopen+milestone%3ACR-Exit+-label%3A%22Pending+
   7+Day+Close%22

     [16] https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is:issue+is:open+milestone:CR-Exit+-label:"Pending+7+Day+Close"

   <brent> manu: there are 17 issues we need to address

   <TallTed>
   [17]https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is
   %3Aopen+milestone%3ACR-Exit+-label%3A%22Pending+7+Day+Close%22+
   sort%3Acreated-desc

     [17] https://github.com/w3c/vc-data-model/issues?q=is:issue+is:open+milestone:CR-Exit+-label:"Pending+7+Day+Close"+sort:created-desc

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

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

   <brent> manu: what we're looking for is any objections with the
   proposed way forward

   Coordinate with PING

   Manu: chairs are continuing to do this

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

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

   PR #436 language support

   Manu: JSON processors cannot support this
   ... this conversion will continue with the I14N team

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

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

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

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

   Manu: a 7 day close will be added to it

   two PRs have been issued for this

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

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

   Manu: this may require a significant amount of work to address
   ... instead we should clarify ToUs so that issue can be
   resolved

   Burn: perhaps we should only add 7 day close to items that
   already have a PR issued for them

   <brent> do we need a resolution for 479?

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

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

   Manu: this is problematic because it is a substantive change if
   it is to be fully addressed
   ... so conversation will continue in the issue.
   ... is anyone going to raise a formal objection is this is not
   resolved?

   <manu> PROPOSAL: The Working Group has discussed issue #480 and
   is not willing to make a substantive change to the
   specification that would trigger another Candidate
   Recommendation phase. The Working Group is interested in
   exploring non-normative resolutions to the issue.

   <manu> DavidC: At what time do we enter another CR? We should
   do that if possible.

   Burn: we have no time to issue a new CR and get the spec
   finished by end of Sept

   <manu> DavidC: What's the process for 1.1?

   <manu> TallTed: The process is another WG

   Burn: we have a defer category to push items to another WG for
   V1.1

   TallTed: this is a perennial issue

   Burn: there are politics involved as well as technical issues
   ... at some point we have to say, go with what we have now,
   rather than risk getting nothing

   TallTed: One constraint is that all things in this spec have to
   continue to work with any new spec

   <Zakim> manu, you wanted to mention "a loose plan"

   Manu: 1.1 spec will go back to the CCG to continue being worked
   on
   ... implementations will continue to work on getting VCs to
   work

   DavidC: what is the status of the implementation guide?
   ... can this be used to advance the standard

   Manu: Yes it can along with the test suite

   <manu> PROPOSAL: The Working Group has discussed issue #480 and
   is not willing to make a substantive change to the
   specification that would trigger another Candidate
   Recommendation phase. The Working Group is interested in
   exploring non-normative resolutions to the issue. The WG would
   like to defer the issue so it can be considered when work
   continues beyond VC 1.0.

   <burn> +1

   <TallTed> +1

   <DavidC> +1

   <deiu> +1

   <brent> +1

   RESOLUTION: The Working Group has discussed issue #480 and is
   not willing to make a substantive change to the specification
   that would trigger another Candidate Recommendation phase. The
   Working Group is interested in exploring non-normative
   resolutions to the issue. The WG would like to defer the issue
   so it can be considered when work continues beyond VC 1.0.

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

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

   this is about multiple subjects with JWT

   Manu: we will add an example to solve this

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

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

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

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

   Manu: we can suggest to implementors that these names may
   change in the future

   <manu> DavidC: The point I raised is that the issuance date is
   not the important date, it's when it's valid from... it's not
   just a change of name, but a change of semantics.

   <manu> DavidC: We could add a second field "validFrom"...
   optional to use, then validFrom == issuanceDate.

   <manu> TallTed: The trouble w/ that is treating issuance as
   valid from is what's going to happen in most cases. A
   conformant processor will treat issuanceDate as validFrom
   whether or not it's present.

   <manu> ken: It seems confusing to put in an alias and have it
   pass the test suite. Don't understand how that's going to play
   out.

   <manu> TallTed: issuance date is not the same as valid from...
   doesn't say anything wrt. validity.

   <Zakim> manu, you wanted to note that the intent was that it
   was "validFrom"

   <Zakim> burn, you wanted to explain 'reserved word' as
   alternative and to mention also that clarifications are okay

   TallTed: are we going to add a new field in the future called
   validFrom?

   DavidC: we only need to change the semantics of the current
   definition and add a note that this date can be in the future

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

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

   Manu: where do JSON developers find the order of @context
   values
   ... they have to search for it

   <manu> DavidC: There are two issues 1) Where do you find the
   human readable text? Can you have description in the @context,
   yes? We could say there is a way to get a human readable bit.

   <manu> manu: Yes, you can put a pointer in there...

   <manu> DavidC: Ok, then I'm happy as long as you can find it
   via a comment.

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

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

   Manu: it we were to add a new JSON property, say description,
   then this will have to be run past the JSON_LD group to OK it

   <brent> DavidC: when I looked at the text, I don't know how to
   take VPs into JWTs

   <manu> DavidC: When I looked at the text, implementing, I don't
   know how to do it... JWT tells us how to turn a VC to JWT...
   take properties out, make them into fields... no equivalent
   text on how to turn VP to JWT.

   <brent> ... the only examples have JSON-LD proofs

   <manu> manu: We could put all this in the implementation guide?

   Manu: we cannot add normative statements to the text so this
   will have to go in the implementors guid

   DavidC: can we also mark it as deferred?

   TallTed: this is why we need another CR

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

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

   Point to an out of date internet draft

   IDs are only valid for 6 months

   So we should never reference IDs

   RFCs are OK as they are long lived

   Manu: we can point to expired ID or to JSON schema web site

   DavidC: I prefer JSON schema web site

   <manu>
   [30]https://datatracker.ietf.org/doc/draft-zyp-json-schema/

     [30] https://datatracker.ietf.org/doc/draft-zyp-json-schema/

   <jonathan_holt>
   [31]https://datatracker.ietf.org/doc/draft-wright-json-schema/

     [31] https://datatracker.ietf.org/doc/draft-wright-json-schema/

   <manu> We should use this URL:
   [32]https://datatracker.ietf.org/doc/draft-handrews-json-schema
   /

     [32] https://datatracker.ietf.org/doc/draft-handrews-json-schema/

   <DavidC> +1

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

     [33] https://github.com/w3c/vc-data-model/issues/596

   Holder should be added to implementation guide

Implementation or other topics

   <manu> [34]https://github.com/w3c/vc-test-suite/pull/15

     [34] https://github.com/w3c/vc-test-suite/pull/15

   <manu> First vc.js implementation report is in!
   [35]https://w3c.github.io/vc-test-suite/implementations/#confor
   mance-testing-results

     [35] https://w3c.github.io/vc-test-suite/implementations/#conformance-testing-results

   Manu: Yancy is having difficulty with putting VCs in the
   playground

   <yancy> [36]https://www.w3.org/2018/credentials/examples/v1

     [36] https://www.w3.org/2018/credentials/examples/v1

   <manu> < content-type: application/octet-stream

   Manu: there is an issue with the way the @context file is
   served.
   ... it should be application json-ld???

   jonathan_holt: is there a plan to create a JSON schema file

   Manu: not for the test suite

   jonathan_holt I support you in this

   Manu: should it be part of the test suite or the implementation
   guide?
   ... we would welcome a PR for the implementation guide

   <DavidC> +1

   Yancy: what is the possibility of modifying the test suite so
   that we dont have any external content

   dmitriz: we could make it standalone content

   Yancy: could we have @context in-line

   dmitriz: we need to provide more documentation about this as
   all implementors will hit it

   <Zakim> kaz, you wanted to mention it sounds like we need to
   modify .htaccess file

   <manu> Two things need to be done: Serve
   [37]https://www.w3.org/2018/credentials/examples/v1 using CORS
   and make sure it's served as application/ld+json

     [37] https://www.w3.org/2018/credentials/examples/v1

   DavidC: we should ensure that must and may is indicated for
   properties
   ... using the Required property

   [adjourned]

Summary of Action Items

Summary of Resolutions

    1. [38]Issue #537 should be addressed by referencing JSON-LD
       1.1 instead of JSON-LD 1.0. This is a non-substantive
       change since the Verifiable Credentials Data Model
       specification included JSON-LD 1.1 features inline for
       JSON-LD based processors and thus implementers would not
       have to change their implementations as a result of the
       updated reference. Issue #537 should be closed after the PR
       is merged.
    2. [39]Issue #551 is addressed by PR #563 which makes
       non-normative changes to fix the missing @context values in
       a number of the examples in the appendix. Issue #551 should
       be closed.
    3. [40]The Working Group has discussed issue #480 and is not
       willing to make a substantive change to the specification
       that would trigger another Candidate Recommendation phase.
       The Working Group is interested in exploring non-normative
       resolutions to the issue. The WG would like to defer the
       issue so it can be considered when work continues beyond VC
       1.0.

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [41]scribe.perl version 1.154 ([42]CVS log)
    $Date: 2019/05/09 10:08:14 $

     [41] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [42] http://dev.w3.org/cvsweb/2002/scribe/

Received on Thursday, 9 May 2019 10:19:42 UTC