Meeting minutes
<brentz> Date: 2022-07-20
brentz: Reviewed agenda
Participation renewal
Expectations for JWT-VC
brentz: Reviewed editors for VC documents
brent: editors of the deliverables that chairs have named. vc-data-model - Manu, Mike J, Orie, and Gabe;...
Goal of topics today is to set goals for each work item and to have conversations around work modes
Orie: Talking about VC-JWT
… Harder to start the work on, probably have enough to get going. Copying over from the current data model only parts relevant to JWT to get started.
<mprorock> +1 orie - copy over existing as a starting place for add ons
Just base components copied over. Opens the door to adding text related to JWT moving forward.
under securing VCs. jwt-vc: MikeJ, Orie; JsonWebSignature2020: Orie, MikeP, MikeJ; Data Integrity: Manu...
<manu> +1 orie - copy VC-JWT section to new spec as a starting place, do a FPWD using that.
Right first step for the group to take.
if interested in being an editor, please reach out to the chairs...
chairs might reach out to you
lol justin
<TallTed> https://
<TallTed> :-)
<sb> +1 and I haven't spoken up yet, but am happy to help edit VC JWT and do whatever Orie and Mike tell me to do :)
<Zakim> manu, you wanted to support
<manu> https://
manu: Supports general proposal. Notes that section of the spec that Orie is referring to is 3.1.
… Only other thing is that there are a couple other issues in the data model that are JWT-specific and should be transferred over.
selfissued: Separate repositories and issue trackers for each spec.
<Zakim> manu, you wanted to note "copy out of data integrity"
selfissued: Once these are copied, next step is to delete them from the existing repositories.
<mprorock> +1 selfissued
manu: Different document for data integrity.
… Data model should just refer to documents to which its contents are copied.
<Orie> I think we will want to remove "proof" examples form the vc data model... at some point.
Expectations for JsonWebSignature2020
brentz: Next topic is JWS-2020.
Orie: WOoking with manu on how to get started.
… Working too.
<mprorock> https://
Orie: Most of the spec work done, confirmed with group that it was OK to move everything over.
… Already opened issue to cover the proposal.
<mprorock> https://
Orie: Existing repo will become read-only archive for history.
… Pull request in CCG to tackle the beginning.
mprorock: Big support for Orie for this repo.
<Orie> Here is the current PR https://
mprorock: Once repo setup is done, in a position to take pull requests.
<Zakim> manu, you wanted to note that I agree with orie wrt. his suggestion for how to handle jws2020.
<Orie> Here is the new repo: https://
manu: +1 to Orie.
… Don't want to apply same process to other repos, need to make different decisions.
<Orie> To be clear, I'm only talking about doing this, for this repo... not the other ones
Orie: Wants to have new rendered version of the spec in the VC working group with a draft title. Wants CI system to take editors' draft revisions.
… Doesn't feel that it's ready to be published in its current form. If we have to do a first publish as first action, still happy to do it that way.
<manu> We don't have to do a FPWD right off the bat.
<Zakim> manu, you wanted to note process, which is squirrely.
manu: W3C process doesn't require FPWD as part of the process of moving the document over to a new repository. FPWD requires working group approval.
… Kicks off the process of handing sets of documents over to the working groups, already started.
… Need to publish through CCG and need to coordinate with staff contact to publish in permanent location and get final IPR commitments.
… All of that can happen in parallel. Don't need to block us doing editors' drafts.
… Usually done in serial.
… Only IPR can affect doing in parallel. That's OK over the next month or two.
… Order of operations: publish as final community group specification, get IPR commitments, move int VCWG, publish as editor's draft.
mprorock: Agrees IPR transfer is the biggest issue. Feels better when stuff is signed off to avoid potential problems.
<Zakim> Orie, you wanted to note you can't publish them in ccg until you have a thing to point to in the wg
<mprorock> +1 editor draft existance
Orie: Get an error when version is not properly specified. First action should be to take an editor's draft that can be pointed to immediately as source for first revision.
kristina_: Thinks IPR requirements are different between working groups and community groups. Reach out to chairs to ensure everything is in order.
<mprorock> +1 kristina - better by the book on this
<Zakim> manu, you wanted to note URL for "latestRevision".
manu: +1 to kristina_
<Orie> This bit here, this is what I would prefer to point to the W3C WG: https://
manu: Process was setup specifically for documents moving from WG to CG.
… Latest revision URL has to point to proper version. Can't point to a GitHub URL, has to be at w3.org.
… +1 to parallelize this.
… Doesn't believe we are creating any risk by working on it in parallel.
<Orie> to get around the "respec" issue, I just pointed it to our charter :) ... I would prefer to have it throw a respec error and point to a proper editors draft.
mprorock: Recent example at IETF where folks got a little hasty and things were not in order, created chaos that didn't need to exist.
… Get moving, but be aware of risk.
<Zakim> manu, you wanted to note timeframe to get sign off, just so folks know.
manu: +1 to mprorock
… Long timeframe to get IPR commitments (up to a month).
<mprorock> +1 manu
manu: Because of the number of documents, it is the editors' jobs to get IPR commitments.
… Sometimes person is non-responsive. Content then reviewed to determine any IPR concerns.
… Group pulls in changes if no issues.
brentz: Supports the notion that we need to work in parallel.
… Not concerned about moving forward with a little bit of boldness.
… One last comment, do not believe we need to make a formal resolution. Does anyone oppose moving the JWS-2020 from CCG to VC WG?
… Heard no oppositionb.
<Orie> I would also like to do an ED for VC-JWT and move over the proof section.
manu: Would prefer that we have a resolution. This is an active thing that the working group is doing, would rather have it on the record.
… No opposition is probably good enough, but resolution would be better.
brentz: Offers to draft proposal or ask others to do so.
can we say CCG?
<TallTed> Proposals can be (and have been) carried by lack of opposition, and then recorded as resolution, but I'm fine to flip to voting. It does help to write the proposal & resolution as such.
brentz: Will go ahead and run the proposal.
<brentz> PROPOSAL: The workgroup will pull in the lds-jws2020 ccg work item into the vcwg and cut an ed for it
<manu> +1
<TallTed> +1
<Orie> +1
<mprorock> +1
+1
<Logan_Porter> +1
+1
<shigeya> +1
<JoeAndrieu> +1
<brentz> +1
<Marty_Reed> +1
<decentralgabe> +1
<selfissued> +1
<sb> +1
<dwaite> +1
RESOLUTION: The workgroup will pull in the lds-jws2020 ccg work item into the vcwg and cut an ed for it
Expectations for Data Integrity
brentz: Moving on to data integrity.
manu: Sent an email to mailing list.
<mprorock> https://
manu: Data integrity specification is a way of doing signatures on JSON-LD document, not specific to Linked Data.
… Base specification, meant to be paired with crypto suites, gives some general parameters around attaching digital proofs to document.
… Crypto suites document explains how to do it using various crypto suites.
<manu> https://
manu: Spec itself is cut to a final CCG specification, with instructions to VC staff to put in permanent location.
<mprorock> +1
<brentz> PROPOSAL: We will use the CCG Data Integrity Spec as the starting point for Data Integrity in the VCWG
<TallTed> +1
<manu> +1
<brentz> +1
<mprorock> +1
<sb> +1
<Marty_Reed> +1
+1
<Orie> +1
<Logan_Porter> +1
<JoeAndrieu> +1
<shigeya> +1
<selfissued> +1
+1
brentz: To manu, do you want to run a proposal for first working draft?
manu: No, let's get a couple editor drafts going.
mprorock: Agreeing to serve as editor.
kristina_: Supports mprorock as editor.
RESOLUTION: We will use the CCG Data Integrity Spec as the starting point for Data Integrity in the VCWG
manu: Thinks that we may want to parallel-track one or two other specs, namely the crypto suites themselves, due to interplay.
brentz: Believe that we should run in parallel as much as we are able.
Data Model FPWD and Issues
<decentra_> +1
+1
<decentra_> proposal to make the proposed proposal a real proposal
kristina_: Asking if should take 1.1 as is.
brentz: Take it as is to be first working draft.
<Zakim> manu, you wanted to note make it more difficult than we need to.
manu: Agrees in principle but it will take a while to get other documents in place.
… Believes we all agree with what's in the document so far.
… Concerned that we will have to wait a bit for data integrity document.
<TallTed> PROPOSAL: We will publish Verifiable Credentials Data Model v1.1 as the FPWD for Verifiable Credentials Data Model v2.0, with plan to ~immediately execute today's change resolutions
<TallTed> bah. action meta key fail.
selfissued: Supports having first editor's draft as copy of VC 1.1 with no changes. First thing we should do after that is remove stuff that is redundant with other specs.
… Doesn't care if that's the first or second working draft. Removal of redundancy should be first work before anything else.
<Zakim> Orie, you wanted to propose getting to EDs as fast as possible
Orie: Get to having editors' drafts as soon as possible. Don't think it's worth cutting the proof section out first.
<Zakim> manu, you wanted to note why FPWD that looks exactly like first cut
Orie: Publish versions only when we feel that they're worthy of being published.
manu: Reason for doing FPWD is to start the IPR process.
<mprorock> +1 manu
manu: Sooner that you start that clock the better.
… If any plan to claim IP, want to know sooner rather than later.
I would be fine too
<brentz> PROPOSAL: We will publish Verifiable Credentials Data Model v1.1 as the FPWD for Verifiable Credentials Data Model v2.0
<Orie> +1
<mprorock> +1
<selfissued> -0
<TallTed> +1
<sb> +1
+1
<brentz> +1
<manu> +1
<decentra_> +1
<oliver> +1
0
<Marty_Reed> +1
<Logan_Porter> +1
<dwaite> 0
<JoeAndrieu> +1
<shigeya> +0
RESOLUTION: We will publish Verifiable Credentials Data Model v1.1 as the FPWD for Verifiable Credentials Data Model v2.0
brentz: Anticipate having more work items. How do we best want to use time in this meeting versus others?
… It's possible that the bulk of the work will happen in other meetings. How do people feel about that?
<Zakim> manu, you wanted to provide some ideas for architectural suggestions for v2.0.
manu: There are a couple things that have been stewing for a while. Need architectural discussions. How are crypto suites related to each other?
… There are things we need to change, such as name and description of a VC in the first iteration.
… Talking about priorities for non-normative work items, might be good to go through charter, ask people where they feel their priorities lie.
… Also have a number of issues that have been backing up that chairs and editors can address.
… Some VC housekeeping things, need to discuss where they go on the roadmap.
selfissued: All of the special topic groups should report progress into the main call.
<brentz> huge +1 on reporting in the main call
selfissued: Main call becomes the coordination point.
<mprorock> +1 selfissued
<Orie> +1 feels the main call should always be about the main data model spec.
thank you!
brentz: Group will still cover topics of interest to group as a whole.
<manu> +1, great work kdeangs1 ! :)