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

Minutes for VCWG telecon 30 April 2019

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Wed, 1 May 2019 17:47:32 +0900
Message-ID: <CAJ8iq9U5Bz_2wm_DfxhE3ZbHb+Bqp_u8FXZ096amaOnJ+7k=kw@mail.gmail.com>
To: public-vc-wg@w3.org
available at:
  https://www.w3.org/2019/04/30-vcwg-minutes.html

also as text below.

Thanks a lot for taking these minutes, Dave and Manu!

Kazuyuki

---

   [1]W3C

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

                               - DRAFT -

                  Verifiable Claims WG Teleconference

30 Apr 2019

   [2]Agenda

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

Attendees

   Present
          Amy_Guy, Andrei_Sambra, Benjamin_Young, Brent_Zundel,
          Dan_Burnett, Dave_Longley, Dmitri_Zagidulin,
          Ganesh_Annan, Kaz_Ashimura, Ken_Ebert, Manu_Sporny,
          Matt_Stone, Sercan_Kum, Ted_Thibodeau, Yancy_Ribbens

   Regrets

   Chair
          Matt_Stone

   Scribe
          manu, dlongley

Contents

     * [3]Topics
         1. [4]Agenda and planning
         2. [5]Issue Lightning Round
         3. [6]Raising Issues for Common Issues
         4. [7]Implementation Reports and Questions
     * [8]Summary of Action Items
     * [9]Summary of Resolutions
     __________________________________________________________

Agenda and planning

   <manu> scribe: manu

   stonematt: Quick Agenda review ... back to processing issues
   and PRs.
   ... We're dealing w/ churn of issues coming out from Tony from
   Microsoft...

   <dlongley> scribenick: dlongley

   burn: Every group does need to be able to say "We're moving on"
   (end of comment period), that doesn't mean you can ignore
   issues that are outstanding but there does need to be an end at
   some point.

   stonematt: We're trying to get to a point with integrity where
   we can say the window for comments is over and we can move on
   from here.

   manu: A lot of these issues really boil down to a couple of
   core philosophical disagreements. The first one has to do with
   whether or not JSON-LD processing is required, it is not. We
   should raise an issue for that.
   ... The second one has to do with making the specification
   purely an extension of JWTs. The group has decided not to do
   that, the VC data model is different from the JWT model.
   ... The third is extension points in the specification, whether
   or not the group was chartered to define the extension points
   or define how they would work that would delve into protocol.

   <burn> I think the JWT issue stems from interop concern, or is
   at least motivated by it

   manu: We can direct the current open issues at one of those
   three issues.

   burn: Every time that issue has come up (interop concern), the
   context has been, you guys have no interop, you need to pick
   something and the thing you need to pick is JWTs.
   ... The basis is to say that it is Tony's claim that it is the
   only technology that is sufficiently well developed to use to
   provide interop.
   ... Proof format, not technology.
   ... We could make three separate issues, but I'd definitely
   want to have a statement in that one that says that's our
   belief.

   manu: Yes, I could nitpick ... I'd rather have three topics.

   burn: That's fine, if it comes down to it, in a transition
   request we'll have to list the disagreements that are
   outstanding and I'm ok with those three and that those
   represent the sum total of the disagreements reflected across
   the sum total of the issues.

   manu: So, Dan, you'll write those three?

   burn: I'll write up drafts and run them by the two of you.

   stonematt: We can write them in a google doc and share the
   link.

   manu: +1

   <dlongley> +1

   burn: Not trying to hide anything, just trying to be efficient
   and a google doc is a great place to do it.

   manu: Bonus points for whomever creates a google doc and puts
   the link in IRC.

   stonematt: I can do that.
   ... Any other comments on this topic today?

   <ken> +1

Issue Lightning Round

   stonematt: We want to close the issues we can. Manu you've been
   leading this discussion and I'll hand it over to you.

   manu: We've got 15 issues to process today.
   ... I'll go back to one we weren't able to get closure on.

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

     [10] https://github.com/w3c/vc-data-model/issues/484

   manu: The issue submitter says the type system is the same as
   the one for JSON-LD and that we shouldn't be forced into
   JSON-LD and allow for JWTs and CWTs and there are many parsers
   out there for JWT/JWS, etc.

   <manu>
   [11]https://github.com/w3c/vc-data-model/issues/484#issuecommen
   t-479922835

     [11] https://github.com/w3c/vc-data-model/issues/484#issuecomment-479922835

   manu: The discussion goes on for a while and then at the very
   end the issue submitter says... This won't work without changes
   to the specification which is effectively no JSON-LD statements
   would be allowed, no `@context`, and JWT claims are allowed,
   JWS/E as proofs and there are other things that will need to be
   documented to allow JWT claims to be used.

   manu reads proposal for addressing the issue

   <manu> PROPOSED: The type system described in the specification
   does not require a JSON-LD processor to be used and the
   concerns raised in issue #484 have been demonstrated to be
   expressible in JWTs using the VC Data Model in a way that is
   both conformant with JWTs as well as other expression
   mechanisms. No technical examples have been provided that
   demonstrate that the type system used for the Verifiable
   Credentials Data Model either 1) requires a JSON-LD processor
   to

   <manu> process, or 2) causes any known JWT library to fail to
   process a JWT containing type information (or any other known
   markup used in the Verifiable Credentials specification).

   <manu> PROPOSED: The WG believes that the type system described
   in the specification does not require a JSON-LD processor to be
   used and the concerns raised in issue #484 have been
   demonstrated to be expressible in JWTs using the VC Data Model
   in a way that is both conformant with JWTs as well as other
   expression mechanisms. No technical examples have been provided
   that demonstrate that the type system used for the Verifiable
   Credentials Data Model either 1) requires a

   <manu> JSON-LD processor to process, or 2) causes any known JWT
   library to fail to process a JWT containing type information
   (or any other known markup used in the Verifiable Credentials
   specification). No changes should be made to the specification.

   <TallTed> +1

   <dlongley> +1

   <ken> +1

   <stonematt> +1

   <deiu> +1

   RESOLUTION: The WG believes that the type system described in
   the specification does not require a JSON-LD processor to be
   used and the concerns raised in issue #484 have been
   demonstrated to be expressible in JWTs using the VC Data Model
   in a way that is both conformant with JWTs as well as other
   expression mechanisms. No technical examples have been provided
   that demonstrate that the type system used for the Verifiable
   Credentials Data Model either 1) requires a

   <manu> JSON-LD processor to process, or 2) causes any known JWT
   library to fail to process a JWT containing type information
   (or any other known markup used in the Verifiable Credentials
   specification). No changes should be made to the specification.

   <SercanK> +1

   manu: Second proposal has to do with that list of things that
   the issue submitter wanted removed from the spec.

   <manu> PROPOSED: The WG has considered the proposals raised in
   Issue #484 and continues to support both JWTs and JSON-LD in
   the specification, continues to support the use of @context as
   it exists in the specification today, supports any valid JWT
   claim expressed in a JWT-based serialization, and supports the
   use of JWS with the specification. The WG has discovered no
   technical reason that JWE cannot also be used to encrypt data
   expressed in the specification. Issue

   <manu> #484 should be closed with no changes to the
   specification.

   <dlongley> +1

   <TallTed> +1

   <ken> +1

   <SercanK> =1

   <SercanK> +1

   RESOLUTION: The WG has considered the proposals raised in Issue
   #484 and continues to support both JWTs and JSON-LD in the
   specification, continues to support the use of @context as it
   exists in the specification today, supports any valid JWT claim
   expressed in a JWT-based serialization, and supports the use of
   JWS with the specification. The WG has discovered no technical
   reason that JWE cannot also be used to encrypt data expressed
   in the specification. Issue

   <manu> #484 should be closed with no changes to the
   specification.

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

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

   Side note: Digital Bazaar is using JWE to encrypt VCs today!

   manu: This issue has to do with the refresh service.
   ... There are multiple PRs related to this.
   ... So we're just verifying that you were ok with the changes
   there, Ken.

   ken: There was a different PR that went in and I felt that the
   issue was done.

   manu: So you feel this issue is done.

   ken: Yeah, I wrote the other PR and got review and it was
   merged.

   manu: PR 501 was replaced by PR 544.

   brent: PR 540 was Ken's it got replaced by PR 544.

   manu: Based on all that, are you ok to close? I've got a
   proposal to close.

   manu reads proposal

   manu: Would you object to the proposal, Ken?

   <manu> PROPOSAL: Issue #458 is addressed by PR #544, which
   makes non-normative changes noting when it is and is not
   appropriate to use the refresh service. The PR has been
   approved by multiple parties and has been merged. Issue #458
   should be closed.

   ken: Can I have a few minutes to review?

   manu: Yes, we'll mark that and come back to it.

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

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

   manu: This was raised by Justin. He said JWS examples use
   detached methods while JWT uses JWS, the detached serialization
   mechanism isn't mentioned in this doc or the linked LD proof
   docs. Dave Longley asked if it would be ok to add informative
   links after the examples and Justin said it would be
   sufficient.

   <manu> PROPOSAL: Issue #470 should be addressed by making a set
   of non-normative changes to the specification that adds a
   simple note after each RsaSignature2018 example with an
   informative reference to that spec and that mentions it used a
   JWS detached signature with an informative reference to the JWS
   spec. Issue #470 should be closed after the PR is merged.

   <TallTed> +1

   manu: Justin was having a hard time tracking down which specs
   were being used and we need to point those out in an
   informative capacity.

   <dlongley> +1

   <deiu> +1

   RESOLUTION: Issue #470 should be addressed by making a set of
   non-normative changes to the specification that adds a simple
   note after each RsaSignature2018 example with an informative
   reference to that spec and that mentions it used a JWS detached
   signature with an informative reference to the JWS spec. Issue
   #470 should be closed after the PR is merged.

   stonematt: Hearing no objections, it is resolved.

   (Kaz joins)

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

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

   <manu>
   [15]https://github.com/w3c/vc-data-model/issues/474#issuecommen
   t-481693698

     [15] https://github.com/w3c/vc-data-model/issues/474#issuecomment-481693698

   manu: Raised by David Chadwick, he's asking whats the
   difference between using `credentialSchema` and the `@context`
   property. I outlined the changes we could make to the
   specification, he hasn't responded to that yet. My expectation
   is that he'd be ok with that. He had a list of changes he'd
   like to see and we need a PR to address those. Specifically...

   <manu> PROPOSAL: Issue #474 should be addressed by making a set
   of non-normative changes to the specification that clarifies
   the use of @context, the differences between it and the
   credentialSchema property, with appropriate references to more
   detailed explanations in the specification and other
   specifications. Issue #474 should be closed after the PR is
   merged.

   manu: For example, one of the things he wanted clarified is a
   JSON-LD thing and we can just point to that spec for that
   particular item. These are all non-normative changes to address
   his concerns and we need to write a PR for that.

   <dlongley> +1

   <TallTed> +1

   <deiu> +1

   stonematt: Any objections?

   RESOLUTION: Issue #474 should be addressed by making a set of
   non-normative changes to the specification that clarifies the
   use of @context, the differences between it and the
   credentialSchema property, with appropriate references to more
   detailed explanations in the specification and other
   specifications. Issue #474 should be closed after the PR is
   merged.

   stonematt: No objections, proposal is resolved.

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

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

   <manu> PROPOSAL: Issue #458 is addressed by PR #544, which
   makes non-normative changes noting when it is and is not
   appropriate to use the refresh service. The PR has been
   approved by multiple parties and has been merged. Issue #458
   should be closed.

   <Zakim> ken, you wanted to say that I can approve the
   resolution regarding PR#544

   ken: I wanted to apologize to the WG for not keeping up with
   that but I can approve the resolution, it was well addressed.

   stonematt: Any objections?

   RESOLUTION: Issue #458 is addressed by PR #544, which makes
   non-normative changes noting when it is and is not appropriate
   to use the refresh service. The PR has been approved by
   multiple parties and has been merged. Issue #458 should be
   closed.

   stonematt: No objections, the proposal is resolved.

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

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

   manu: When you encode a VC in a JWT there is a processing step
   that says you use the `sub` field in the JWT and that it should
   mention the subject in the credential. A VC can be about
   multiple subjects and JWTs do not support multiple subjects.
   For example, marriage certificates. The discussion goes on for
   a little bit.
   ... I made a suggestion that notes that JWTs can only currently
   support single subjects and implementers should check the JWT
   claim registry for multiple subjects. Tony also suggested
   something else to reference and it's not a 1:1 mapping to the
   problem but Tony would like us to reference it. All we need to
   do, I believe, is create a PR for that.

   <manu> PROPOSAL: Issue #511 should be addressed by making a
   non-normative change to the specification noting that multiple
   subjects are not supported by JWTs and implementers should
   refer to the JWT registry for future multisubject properties or
   the yusef-nested-jwt specification. Issue #511 should be closed
   after the PR is merged.

   manu: So, whomever cares about that use case for JWTs will go
   out to IETF and create that extension it's not up to us. We'll
   just add some informative references and let people know this
   isn't supported by JWTs at the moment.

   <TallTed> +1

   <dlongley> +1

   <ken> +1

   stonematt: Any objections?
   ... The proposal is resolved.

   RESOLUTION: Issue #511 should be addressed by making a
   non-normative change to the specification noting that multiple
   subjects are not supported by JWTs and implementers should
   refer to the JWT registry for future multisubject properties or
   the yusef-nested-jwt specification. Issue #511 should be closed
   after the PR is merged.

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

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

   manu: I raised this issue that we need a VC status registry and
   more than likely we need other registries and we need a
   combined registry, if no one else gets to it I'll take an
   action for it.

   <manu> PROPOSAL: Issue #530 should be addressed by creating a
   Verifiable Credentials Extension Registry in the W3C
   Credentials Community Group and requesting that the registry is
   adopted as an official W3C CCG Work Item. Issue #530 should be
   closed after the W3C CCG accepts the registry as a Work Item.

   ken: How does that work, after the CCG says they will take it
   on it becomes not our responsibility anymore?

   manu: Yes, if you want to add an extension to the registry you
   talk to the CCG. It's the same thing as doing, for example, a
   DID method spec. You create a spec and ask the CCG for
   inclusion into the registry and there's a lightweight process
   to add it and then it's there.

   ken: That's sufficient.

   <TallTed> +1

   <ken> +1

   <dlongley> +1

   <gannan> +1

   RESOLUTION: Issue #530 should be addressed by creating a
   Verifiable Credentials Extension Registry in the W3C
   Credentials Community Group and requesting that the registry is
   adopted as an official W3C CCG Work Item. Issue #530 should be
   closed after the W3C CCG accepts the registry as a Work Item.

   stonematt: No objections, it is resolved.

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

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

   <manu> PROPOSAL: Issue #543 should be addressed by providing
   informative references to detached JWS, LD-Proofs,
   LD-Signatures, and the RsaSignature2018 signature suite in
   sections 3.4, 3.7, and any other section where it is
   appropriate. Issue #543 should be closed after the PR is
   merged.

   manu: This is actually the same kind of issue that Justin
   raised in that other issue, it's to add references to 3.4 and
   4.7, anywhere we talk about a full proof and to link to LD
   proofs and JWS detached, etc. Just to make non-normative
   references to those things if they care about implementing
   them.

   <dlongley> +1

   <TallTed> +1

   stonematt: Any objections?
   ... No objections, it is resolved.

   RESOLUTION: Issue #543 should be addressed by providing
   informative references to detached JWS, LD-Proofs,
   LD-Signatures, and the RsaSignature2018 signature suite in
   sections 3.4, 3.7, and any other section where it is
   appropriate. Issue #543 should be closed after the PR is
   merged.

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

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

   <brent> +1 to removing the disputes section to implementation
   guide

   <ken> +1 to what brent said

   manu: Let's modify the dispute section, talk about the loose
   intention there, the group didn't get to defining it fully but
   put it in the implementation guide.

   <manu> PROPOSAL: Issue #545 should be addressed by moving the
   majority of the Disputes section to the Implementation Guide
   and referring to that section from the Data Model
   specification. Issue #545 should be closed after the PR is
   merged.

   <ken> +1

   stonematt: Any objections?

   TallTed: Does that change the section to non-normative? Let's
   be explicit ... "by moving the majority of the at-risk"...

   <manu> PROPOSAL: Issue #545 should be addressed by moving the
   majority of at risk Disputes section to the Implementation
   Guide and referring to that section from the Data Model
   specification, and making the Disputes section in the VC Data
   Model specification non-normative. Issue #545 should be closed
   after the PR is merged.

   <TallTed> +1

   stonematt: Any objections?

   <dlongley> +1

   <ken> +1

   stonematt: It is resolved.

   RESOLUTION: Issue #545 should be addressed by moving the
   majority of at risk Disputes section to the Implementation
   Guide and referring to that section from the Data Model
   specification, and making the Disputes section in the VC Data
   Model specification non-normative. Issue #545 should be closed
   after the PR is merged.

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

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

   manu: Yancy raised this issue, we talked about it last week
   about how he'd be happy with changing this. The issue here is
   that Yancy is saying you have to download the JSON-LD
   `@context` and that's problematic. And the assertion is that
   "no you don't."
   ... You literally never have to go out to the Web. If you're
   using the credentials context.
   ... If the other context you're using doesn't say it's cached
   forever you may have to get it but it can also say that and
   that's an expectation that we will underscore in the best
   practices document.
   ... Wondering if we can flatten all the contexts, there are
   three, the VC one, the security v1 and security v2 context.
   That requires you to load multiple contexts [from disk, not
   required from the Web].
   ... We would then refer to the context and provide a SHA-256
   hash of that context in the spec.

   <rhiaro> *and* a human readable copy in the spec appendix
   right? because, for humans?

   manu: These are non-substantive changes to the specification
   and some shuffling.
   ... Amy is also asking another question we should address in
   the spec as well
   ... First question to Longley is can we flatten everything and
   it's fine?

   <rhiaro> but if *all* you have is the spec, you can still
   implement and hard code or cache your context in an
   implementation

   <rhiaro> isn't that what appendices are for? :)

   manu: Second question is can we put the human readable version
   in the spec ... and I say we shouldn't have to is because if
   the hash is there you can fetch it and check it.

   TallTed: I think including it makes various different kinds of
   sense.
   ... Moving it out is hard to argue. The consistent intro to
   this thread is "you literally never have to go out to the Web,
   unless, unless, unless"
   ... In the first iterations, no one is going to use a different
   context. Arguments that you never have to go anywhere to get
   anything are spurious.

   manu: In dev mode you ahve to do that and experiment, In
   production you are expected to freeze and we should put that in
   production.

   <manu> ken: Two questions - one about effect of squashing
   @context - does that have any interop problems?

   <rhiaro> +1 you have to get it at some point, and maybe this is
   a silly premise but if all you have is a printout of the spec
   you can still make an implementation compeltely offline and
   include it, if the context is in the spec. I also think i'ts
   just generally useful for people skimming this stuff

   <manu> ken: second, time to cache... is there a mechanism in
   production that you're not changing anymore and ok to cache
   forever.

   manu: Answer to the first question is that squashing doesn't
   have any interop issues, zero, no known issues. The time to
   cache issue can be done with an HTTP cache -- I believe there
   are some that are cache forever.
   ... In the spec it says you can cache forever.
   ... There are two ways to do that.

   ken: Is it that during development that the expectation that a
   context could change but at production it will not.
   ... Does that apply to the ones the WG has put together and
   also others? For specific schemas for those credentials?

   manu: That is up to whomever creates those, but we can put it
   in the best practices that you should absolutely do that.
   ... Dev mode it can change, but production it should never
   change.

   <manu> dlongley: First thing, code that we've written that uses
   VC stuff, and verification code... production code pulls all
   contexts from disk... people can write their code that way, no
   reason to go out to web in production mode.

   <manu> dlongley: Can we flatten the context, I think so, we
   should do it and see if there are implementation problems and
   if not, proceed that way.

   <manu> dlongley: We are currently writing implementations
   against that context, we can change the context in CR, once we
   move on from that, it'll be locked in.

   manu: Amy says "If all you have is a print out of the spec you
   can implement" ... so Ted and Amy are +1 for putting the
   context in the spec directly.

   <TallTed> retaining SHA-256 is still good

   ken: When you're squashing the contexts -- you're taking some
   things that have been standardized or written by another
   organization, is it clear that this chunk of the context came
   from this original source?

   manu: Yes, because we use URLs for everythin.g

   <rhiaro> and it isn't *that* big if it's just credentials and
   security v1 & v2 isn't it..?

   manu: That may not be the full answer to your question. The
   context we're using the security v1 and v2 stuff -- DB has been
   in control of those contexts until this WG took control.
   ... When we squash into the vc v1 context it's under the full
   control of this group, but we might call out to other
   vocabularies.
   ... We'll review to make sure all that stuff is safe to do. I
   did look through all the contexts and it did look doable before
   I wrote this proposal up.

   TallTed: I think keeping the SHA-256 is good. The file is at
   this URL and here's the SHA-256, put that in the appendix.

   <stonematt> +1 to keeping SHA-256 reference

   <ken> +1 to teds suggestion

   <yancy> +1 to SHA-256 ref

   <rhiaro> +1 also to the sha256

   <manu> PROPOSAL: Issue #549 should be addressed by flattening
   all contexts that the specification depends on into
   [22]https://www.w3.org/2018/credentials/v1, adding the JSON-LD
   Context into an appendix in the spec along with its SHA-256
   hash, all of which would be a non-substantive modification.
   Issue #549 should be closed after these actions are taken.

     [22] https://www.w3.org/2018/credentials/v1,

   <TallTed> +1

   <dlongley> +1

   <deiu> +1

   <yancy> +1

   <ken> +1

   <rhiaro> +1

   <bigbluehat> +1 (with necessary cautions)

   stonematt: Any objections?

   RESOLUTION: Issue #549 should be addressed by flattening all
   contexts that the specification depends on into
   [23]https://www.w3.org/2018/credentials/v1, adding the JSON-LD
   Context into an appendix in the spec along with its SHA-256
   hash, all of which would be a non-substantive modification.
   Issue #549 should be closed after these actions are taken.

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

   stonematt: No objections, resolved.

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

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

   manu: Raised by Ted, about identifiers, asked him to raise a PR
   and I reviewed, no substantive changes.

   <manu> PROPOSAL: Issue #556 should be addressed by applying the
   non-substantive changes requested by the issuer submitter.
   Issue #556 should be closed after the PR is merged.

   TallTed: As I noted in the PR, there is a neighboring
   definition and these two chunks of text overlap a bit and I'm
   not sure what the best text is to deal with that.

   manu: I'll take a look.

   TallTed: It's somewhat clumsy but I don't think there's
   disagreement between the two.

   manu: I'll see what I can do with my next editorial pass.
   ... Any disagreements with this proposal?

   ken: Are those are normative language changes?

   <yancy> I can work on a PR for 549

   manu: There are changes to normative language that are
   non-substantive, it is a clarification, it won't change
   implementations at all.

   TallTed: Implementers would change nothing if they understood
   the wording correctly in the first place.

   ken: Just wanted to deal with CR issues.

   manu: If anyone complains they'll have to defend it -- it's
   very clear.

   stonematt: Any objections?
   ... No objections, resolved.

   RESOLUTION: Issue #556 should be addressed by applying the
   non-substantive changes requested by the issuer submitter.
   Issue #556 should be closed after the PR is merged.

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

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

   manu: Thanks, Yancy for volunteering, might need review from
   Dave Longley.
   ... I tried to clarify what I thought this JWT encoding section
   meant.

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

     [26] https://github.com/w3c/vc-data-model/pull/583

   manu: Ted made a PR to address.
   ... Ted, anything else you want to add?

   TallTed: I'm fine with the things I wrote. :)

   <manu> PROPOSAL: Issue #552 should be addressed by making a
   non-normative clarification related to the various ways the
   data model can be encoded using a JWT. Issue #552 should be
   closed after the PR is merged.

   <yancy> I'm having phone issues. Will run PR by dlongley.

   stonematt: Hearing no objections, resolved.

   <brent> +1

   <ken> +1

   RESOLUTION: Issue #552 should be addressed by making a
   non-normative clarification related to the various ways the
   data model can be encoded using a JWT. Issue #552 should be
   closed after the PR is merged.

   <ken> +1

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

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

   manu: This is about the `@context` being an ordered set.
   ... Making it not an ordered set would argue against the point
   of avoiding a JSON-LD processor, so we added PRs about the
   order being important.

   <manu> PROPOSAL: Issue #557 is addressed by PR #546 which made
   non-substantive changes to explain why @context is an ordered
   set. PR #546 has been merged and issue #557 should be closed.

   <dlongley> +1

   <bigbluehat> +1

   TallTed: Not an objection per se, there's an open comment on
   546.

   manu: I'll ask David Chadwick about that.
   ... For him to open a new issue if needed.

   <TallTed> +1

   manu: Ted, I'm asking David to open a new issue if that's
   really important to him.

   TallTed: That's fair.

   stonematt: Any objections to the proposal?

   RESOLUTION: Issue #557 is addressed by PR #546 which made
   non-substantive changes to explain why @context is an ordered
   set. PR #546 has been merged and issue #557 should be closed.

   stonematt: No objections, proposal is resolved.

   manu: Two more to go.

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

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

   manu: This has to do with processing contexts, also raised by
   Tony.
   ... He's saying that it is recommended that dereferencing the
   URIs in the spec and that that text should be removed and that
   it can be large security attack vector to dereference documents
   on the Web.
   ... That's not what the text says, it says "only if you
   dereference it should you get a machine readable doc", you
   don't have to do that and we have additional text now saying
   you don't have to go out to the Web for the VC context and
   we'll add text to the best practices doc to say not to
   dereference in production.

   <manu> PROPOSAL: Dereferencing a value in the @context property
   should result in a document containing machine-readable
   information about the context. Issue #558 should be closed with
   no change to the specification.

   <dlongley> +1

   <ken> no further change to the specification?

   <manu> PROPOSAL: Dereferencing a value in the @context property
   should result in a document containing machine-readable
   information about the context. Non-normative clarification text
   should be added to the specification to underscore that
   dereferencing machine-readable @contexts is optional. Issue
   #558 should be closed with no change to the specification.

   <manu> PROPOSAL: Dereferencing a value in the @context property
   should result in a document containing machine-readable
   information about the context. Non-normative clarification text
   should be added to the specification to underscore that
   dereferencing machine-readable @contexts is optional. Issue
   #558 should be closed when the PR #564 is merged.

   <ken> +1

   <dlongley> +1

   <TallTed> +1

   <gannan> +1

   stonematt: Any objections?

   RESOLUTION: Dereferencing a value in the @context property
   should result in a document containing machine-readable
   information about the context. Non-normative clarification text
   should be added to the specification to underscore that
   dereferencing machine-readable @contexts is optional. Issue
   #558 should be closed when the PR #564 is merged.

   stonematt: No objections, resolved.

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

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

   manu: This is about verifiable presentations. Tony is saying
   VPs are non-normative because there's no interop on VPs. This
   is the same thing that has been raised multiple times where his
   claim is that you can't create specs with extension points
   without defining any extensions and protocols themselves.
   ... He says we introduce VPs in a non-normative fashion that
   everything about them should be non-normative, but that makes
   no sense. Often specs introduce concepts in an informative way
   because no normative statements are made and then those are
   made later.
   ... We meant to mark the introduction as non-normative and the
   part where it talks about the presentation in the data model as
   normative.

   <manu> PROPOSAL: It is common practice, both at W3C and IETF,
   to introduce concepts in a non-normative fashion and then
   provide normative statements in the more technical parts of the
   specification. Readers are urged to note whether sections are
   marked as non-normative and should not assume that other
   sections discussing the same concept are non-normative as well.
   Issue #559 should be closed with no changes to the
   specification.

   <TallTed> +1

   <dlongley> +1

   <ken> +1

   <gannan> +1

   RESOLUTION: It is common practice, both at W3C and IETF, to
   introduce concepts in a non-normative fashion and then provide
   normative statements in the more technical parts of the
   specification. Readers are urged to note whether sections are
   marked as non-normative and should not assume that other
   sections discussing the same concept are non-normative as well.
   Issue #559 should be closed with no changes to the
   specification.

   stonematt: Hearing no objections, resolved.

   manu: Thank you everyone, that is the last issue I have -- and
   the last one I have in the issue tracker as of this morning...
   Ted raised another one but that's fine.
   ... We may have 2-4 CR issues remaining to still process, but
   this is the majority of the CR issues. We need to get PRs in
   for a lot of these resolutions. I really need help doing that.
   If there is a CR issue that has a "Needs PR" tag on it (search
   for that) and you feel that you can create a PR for it, please
   please help.
   ... That will make things go much faster. Thank you very much
   to Ted for helping with a ton of editorial changes moving
   things forward, thanks to Brent, and Ken, and David Chadwick as
   well -- if we can more of your help and help from others in the
   group then we can very quickly close up to 48 of these issues.

   <stonematt> Thanks to all who have been contributing PRs this
   month

   manu: That's it. Back over to Matt.

Raising Issues for Common Issues

   <stonematt>
   [30]https://docs.google.com/document/d/1U4Krhjl1dMK294JFp9JuIz_
   zmom2zh2CN94Sc0yPpxU/edit

     [30] https://docs.google.com/document/d/1U4Krhjl1dMK294JFp9JuIz_zmom2zh2CN94Sc0yPpxU/edit

   stonematt: Thank you. I want to come back to the common issue
   thread. We will try to come to together around some fundamental
   philosophical issues where we see duplication across a variety
   of open issues.
   ... We opened a google doc to draft text for addressing that.
   ... We will raise 2-3 common issues and Dan Burnett will take
   lead on writing that. I won't say don't contribute, but he'll
   lead.
   ... For issues that are essentially just duplicates of those
   fundamental issues we'll reference that.
   ... Keep your eyes peeled for changes to that doc.

Implementation Reports and Questions

   stonematt: We want to open the floor -- we have 20 minutes left
   on the call today, we can use as much of it as we need to open
   the implementation report discussion/.

   <Zakim> manu, you wanted to ask about vc-js implementation
   report, and updates to test suite... dmitriz ?

   manu: Where's the vc-js implementation report and test suite
   status?

   dmitriz: There's a pending PR to the test suite that adds a
   couple more changes that we put in for CR. Some more fields
   have become required since before CR.
   ... That updates the test suite with those changes and there's
   an implementation report from DB's vc-js library.
   ... Look early and often for changes, we should be good on our
   end.
   ... In response to Brent's question a couple days ago, I left
   instructions on how to hook up your own library to the test
   suite.

   manu: There's a report, but we haven't run the processor to
   update the page yet?

   dmitriz: Right, I probably misunderstood the directions, I
   thought the report generates and processes in one command.

   manu: I don't remember, we should get it so that everyone can
   see what a successful test report looks like.

   dmitriz: Ok.

   stonematt: Do we have something along the lines of a tutorial
   or recipe guide for how to do all that as well?

   dmitriz: It's in an issue at the moment and we can cut and
   paste that into a standalone document.

   stonematt: Can we have that in a README?

   <manu> We should put it here ---
   [31]https://w3c.github.io/vc-test-suite/

     [31] https://w3c.github.io/vc-test-suite/

   dmitriz: It's a little informal at the moment, I would like
   feedback from Brent and other implementers as to if it made
   sense.

   manu: If you put that link from IRC into the browser it tells
   you how to run the test suite and we should put that HOWTO from
   the issue in there.

   <dmitriz> [32]https://github.com/w3c/vc-test-suite/issues/14

     [32] https://github.com/w3c/vc-test-suite/issues/14

   dmitriz: That's fine.

   <ken> Putting the instructions in the doc would be helpful.

   manu: We may also want to point to the issue with vc-js verify.

   dmitriz: The comment in the issue goes into that.

   brent: I haven't had a chance to try that out yet, it helps me
   having a document we can update as more questions come in.

   <stonematt> +1 to a README or "HOWTO"

   brent: +1 to moving the comments from an issue to a document.

   <Zakim> manu, you wanted to note README

   <manu> [33]https://w3c.github.io/vc-test-suite/

     [33] https://w3c.github.io/vc-test-suite/

   manu: +1 to a strong preference for putting everything in the
   README.
   ... My hope is that the URL I put in IRC is the place people
   can go to find out what implementations exist that are
   conformant to the specification as well as how to write your
   own, hook up to the test suite, etc.
   ... One stop shop for all of that, current implementations,
   what they support, what they don't, how you can write your own.
   Having more than one place for that is confusion, so just one
   place, that README would be good.

   stonematt: That makes sense, right marching orders for Dmitri
   or whomever to make updates.
   ... Any other questions about test suite or implementation
   reports today?

   none

   stonematt: That covers our agenda, we had a placeholder for
   scheduling ad hoc discussion if necessary from the issue
   lightning round, I didn't hear any. If anyone needs discussion
   this week, raise your hand now, otherwise we're done for the
   day.
   ... Any other business?
   ... Ok, 10 minutes back. Thanks for a great call, got through a
   ton of stuff and really appreciate everyone's attention and
   focus on the spec in the last few weeks and we've made a ton of
   fine tuning contributions and it's coming together in a nice
   way, good bye!

   <stonematt> good bye everyone!

Summary of Action Items

Summary of Resolutions

    1. [34]The WG believes that the type system described in the
       specification does not require a JSON-LD processor to be
       used and the concerns raised in issue #484 have been
       demonstrated to be expressible in JWTs using the VC Data
       Model in a way that is both conformant with JWTs as well as
       other expression mechanisms. No technical examples have
       been provided that demonstrate that the type system used
       for the Verifiable Credentials Data Model either 1)
       requires a
    2. [35]The WG has considered the proposals raised in Issue
       #484 and continues to support both JWTs and JSON-LD in the
       specification, continues to support the use of @context as
       it exists in the specification today, supports any valid
       JWT claim expressed in a JWT-based serialization, and
       supports the use of JWS with the specification. The WG has
       discovered no technical reason that JWE cannot also be used
       to encrypt data expressed in the specification. Issue
    3. [36]Issue #470 should be addressed by making a set of
       non-normative changes to the specification that adds a
       simple note after each RsaSignature2018 example with an
       informative reference to that spec and that mentions it
       used a JWS detached signature with an informative reference
       to the JWS spec. Issue #470 should be closed after the PR
       is merged.
    4. [37]Issue #474 should be addressed by making a set of
       non-normative changes to the specification that clarifies
       the use of @context, the differences between it and the
       credentialSchema property, with appropriate references to
       more detailed explanations in the specification and other
       specifications. Issue #474 should be closed after the PR is
       merged.
    5. [38]Issue #458 is addressed by PR #544, which makes
       non-normative changes noting when it is and is not
       appropriate to use the refresh service. The PR has been
       approved by multiple parties and has been merged. Issue
       #458 should be closed.
    6. [39]Issue #511 should be addressed by making a
       non-normative change to the specification noting that
       multiple subjects are not supported by JWTs and
       implementers should refer to the JWT registry for future
       multisubject properties or the yusef-nested-jwt
       specification. Issue #511 should be closed after the PR is
       merged.
    7. [40]Issue #530 should be addressed by creating a Verifiable
       Credentials Extension Registry in the W3C Credentials
       Community Group and requesting that the registry is adopted
       as an official W3C CCG Work Item. Issue #530 should be
       closed after the W3C CCG accepts the registry as a Work
       Item.
    8. [41]Issue #543 should be addressed by providing informative
       references to detached JWS, LD-Proofs, LD-Signatures, and
       the RsaSignature2018 signature suite in sections 3.4, 3.7,
       and any other section where it is appropriate. Issue #543
       should be closed after the PR is merged.
    9. [42]Issue #545 should be addressed by moving the majority
       of at risk Disputes section to the Implementation Guide and
       referring to that section from the Data Model
       specification, and making the Disputes section in the VC
       Data Model specification non-normative. Issue #545 should
       be closed after the PR is merged.
   10. [43]Issue #549 should be addressed by flattening all
       contexts that the specification depends on into
       https://www.w3.org/2018/credentials/v1, adding the JSON-LD
       Context into an appendix in the spec along with its SHA-256
       hash, all of which would be a non-substantive modification.
       Issue #549 should be closed after these actions are taken.
   11. [44]Issue #556 should be addressed by applying the
       non-substantive changes requested by the issuer submitter.
       Issue #556 should be closed after the PR is merged.
   12. [45]Issue #552 should be addressed by making a
       non-normative clarification related to the various ways the
       data model can be encoded using a JWT. Issue #552 should be
       closed after the PR is merged.
   13. [46]Issue #557 is addressed by PR #546 which made
       non-substantive changes to explain why @context is an
       ordered set. PR #546 has been merged and issue #557 should
       be closed.
   14. [47]Dereferencing a value in the @context property should
       result in a document containing machine-readable
       information about the context. Non-normative clarification
       text should be added to the specification to underscore
       that dereferencing machine-readable @contexts is optional.
       Issue #558 should be closed when the PR #564 is merged.
   15. [48]It is common practice, both at W3C and IETF, to
       introduce concepts in a non-normative fashion and then
       provide normative statements in the more technical parts of
       the specification. Readers are urged to note whether
       sections are marked as non-normative and should not assume
       that other sections discussing the same concept are
       non-normative as well. Issue #559 should be closed with no
       changes to the specification.

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [49]scribe.perl version 1.154 ([50]CVS log)
    $Date: 2019/05/01 08:46:12 $

     [49] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [50] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 1 May 2019 08:48:39 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 1 May 2019 08:48:40 UTC