Verifiable Credentials WG Telco — Minutes

Date: 2022-03-30

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Michael Prorock, David Chadwick, Aaron Coburn, Dave Longley, Charles Lehner, Kristina Yasuda, Markus Sabadello, Michael Jones, Shawn Butterfield, Orie Steele, Justin Richer, Dmitri Zagidulin, Ted Thibodeau Jr.

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Markus Sabadello, Charles Lehner

Content:

Brent Zundel: We use IRC for meeting minutes and handling queue.
… Please type present+ to record your present.
… Let’s review the agenda, apologies for sending it late.
… Intros, charter PRs, and make a resolution.

Manu Sporny: Need 2 minutes please to announce something.

Brent Zundel: Let’s do that after introductions.

Shawn Butterfield: I’m principal software engineer at Salesforce. One of the platforms I am building is for VC management for enterprises and non-profits. We’re getting into usefulness of DIDs beyond VCs. Happy to be here and contribute, I think an important part of being a creator is being part of the ecosystem.
… We acquired Credential Master and partner with others.
… Credential Master application was a proof-of-concept that proved viability of VCs for Salesforce. Will be de-composed into broader set of platform functionalities.

Manu Sporny: In VC 1.0 WG we had an extension registry. We handed that over to CCG to manage, and not much happened for a very long time.

Manu Sporny: See Extension registry by the CCG.

Manu Sporny: More recently, IMS Global (for education sector) has been looking for crypto suites that they will support. Ed25519Signature2020 came up. They wanted to reference it in their specs but couldn’t point anywhere. They suggested to point to extensions registry.
… PR is open on the extension registry now.
… Code owner entries are really old.
… We haven’t re-visited the process of adding extensions. Not sure how much this group wants to be involved with this.

Michael Jones: Manu give me a bit more on the process you use for registering algorithms.

Manu Sporny: See Registry registration process.

Manu Sporny: Registry defines the registration process.
… VCWG signed off on this in its first iteration. It’s pretty straightforward. You have to implement the extension, create a specification, then request it to be added via Github PR.

Michael Jones: What algorithm are you registering?

Dave Longley: it’s not an algorithm, it’s a cryptosuite.

Manu Sporny: It’s specifically the Ed25519Signature2020 (Edwards curve). The spec and implementation are linked in the PR.

Michael Jones: Thank you that’s a good clarification.

1. VCWG Charter - PRs.

Brent Zundel: https://github.com/w3c/vc-wg-charter/pulls.

Brent Zundel: Looking at 2 PRs now.

1.1. Add Koblitz ECDSA Recovery Cryptosuite (pr vc-wg-charter#105)

See github pull request vc-wg-charter#105.

Brent Zundel: This was raised by cel , can you talk us through it. (Charles Lehner).

Charles Lehner: This adds Koblitz ECDSA Recovery Cryptosuite.
… It’s similar to other mentioned suites for other algorithms.
… It’s JWS based with detached mode. Incorporates new unregistered JWA. This is at DIF.

Michael Prorock: See EcdsaSecp256k1RecoverySignature2020.

Manu Sporny: +1 to this. Supportive of this.
… At some point we need to understand by which DIF releases these specs, so that this WG can pick it up and use it.
… I hope the group that creates it operates in W3C mode, not sure if we have ever handed over a spec from DIF.

Manu Sporny: I don’t anticipate it being a problem either, we just need to have an answer for W3C legal.

Brent Zundel: There is an Apache license on the repo. I agree we need to interact with DIF to more formally handle it. I don’t anticipate a problem considering the license.
… This PR had positive feedback. Anyone opposed to merging it?
… Hearing no opposition, will merge it.

1.2. updating algorithms-related reference documents for jwt-vcs (pr vc-wg-charter#107)

See github pull request vc-wg-charter#107.

See github issue vc-wg-charter#88.

Brent Zundel: This was raised by kristina.
… Can you walk us through this?

Kristina Yasuda: Addresses issue 88. For the cryptosuites we are only referencing CCG documents which define algorithms.
… But not for JWT VCs.
… I got the question a few times, what does that mean. The purpose was to clarify the cryptosuites that would be used for JWT VCs.
… I thought JOSE registry was the most concise way.
… Is there a better way to portray concerns about the context. The PR is an attempt to do so.

Michael Jones: I find manu ‘s comments a bit confusing. He seems to be assuming input documents we would take over and modify. That’s not that list.
… Input documents will inform the work. I applaud kristina since this is a really concise to reference input documents.

Manu Sporny: My understanding of input documents is quite different from that. An input document is a document that is specifically an input for the WG. The WG is taking it over and may or may not change it.
… Inputs are taken over to create deliverables.
… The reason why it’s important to specify them is to establish IP commitments. This should be reviewed by legal council, as the technologies that the group will touch directly. It establishes an IPR scope.
… I think this understanding of input documents has been pretty consistent across W3C WGs.
… This PR feels like a no-op, nothing changes if we accept or not accept it. In the best case.
… In the worst case, we list IANA registry as input document, which it is not. We reference it, not use it as input document.
… CCG input documents reference IETF RCFs. Therefore we don’t have to mention them in the charter.
… What are we attempting to accomplish with this text? What’s the concrete goal of this PR, I don’t understand it right now.

Ted Thibodeau Jr.: My intuitive understanding of input docs is closer to selfissued than manu. I’m searching from some definition and can’t find one.
… If that definition exist, we should be able to link to it and also gain understanding from it.
… Failing that definition, then I’m siding with selfissued with what that list should do. It’s basis for continuing work, not work that we’re going to subsume and replace.

Orie Steele: +1 justin, mike and ted.

Justin Richer: It seems very strange to cite IPR protections as motivating factor for listing input documents, since input documents traditionally are documents the group will look at to create new things. Any text that is taken in has to be vetted regardless of its original source.
… My concern with listing input documents is that this would be used as a limiting function to the WG; somebody would use this list to say that we can’t talk about something because it’s not in the list of input documents. That worries me about having things explicitly listed.

Michael Prorock: +1.

Justin Richer: Charters are meant to guide the WG. It’s up to chairs and WG and SDO to interpret the charter to help the WG do its job. Not a strict recipe for the WG to follow.

Michael Jones: manu unless you can find W3C document which explains the term “input documents” in the manner that you’re interpreting it, I suggested it would be more reasonable to use plain English meaning, which TallTed and justin_r and others have just supported.

Justin Richer: +1 to plain english (as opposed to a defined separate term).

Michael Jones: This is a concise way to listen important inputs, otherwise we would have a much longer list. I will reserve judgement based on whether manu can find W3C document that says what we mean by “input document”.

Justin Richer: @manu “input document” does not occur in that page, and the only uses of “input” are simple plain english.

Kristina Yasuda: It’s to clarify the documents that we would look into when we work on JWT VCs.
… Regarding definition of “input document”, I did try to look for a definition, unfortunately I couldn’t find it. Can you provide a definition, then I’m happy to change PR accordingly.

Manu Sporny: See W3C process document.
See W3C patent policy.
I’m just providing links – “input document” has no official definition at W3C. I can just speak to how it’s been used in Patent Advisory Groups in the past.

Justin Richer: if it has no official meaning, then why are you using it as a term?

Michael Jones: The W3C process document doesn’t speak about Input Documents, as far as I can tell.

Michael Jones: I’m fine with “input documents include”.

Ted Thibodeau Jr.: Limiting factor concern can be handled by a phrase that says the list is not exhaustive. Or similar phrasing. Then there’s no limiting factor.

Justin Richer: +1 to TallTed.

Kristina Yasuda: Justin, did you mean to imply none of the input documents should be listed?

Brent Zundel: At first my understanding was the same as manu’s, but reading through the process it is quite broad of what it expects. We must describe the nature of deliverables. If an deliverable is based on previous document, then we have to say what those are.

Justin Richer: @kristina: no I’m saying that listing input documents just means “this is a bunch of stuff we’re going to look at”.

Kristina Yasuda: it already says “The following are a non-exhaustive selection of input documents”.

Justin Richer: @kristina: you could list a blog post as an “input document”.

Brent Zundel: If there still is a concern about intentions on our part to take over those things, we should add additional language. Those concerns should be no reason to not merge the PR.

Manu Sporny: There is no official definition, we talked about this in a previous meeting. I thought it was clear, but it seems there isn’t. Should we define what we mean by input document.
… I’m -1 on this, but I will not stand in the way.

Michael Jones: There was a suggestion in chat to say “input documents include…”. I’m fine with this clarification.

Brent Zundel: The charter already has the sentence: “The following are a non-exhaustive selection of expected input documents:”.

Michael Jones: Defining terms such as “input documents” is going too meta for me. The English meaning is clear enough.

Ted Thibodeau Jr.: Existing “non-exhaustive selection” language seems sufficient to me.

Kristina Yasuda: to me too.

Michael Prorock: plenty of other examples out there in this regard: https://github.com/w3c/dpubwg-charter/commit/c4db6475a61cc56075a7183a8fb04bf52faaaa3c.

Justin Richer: I wanted to provide a quick definition what input and output documents mean.
… Input documents is something you read and you might take text from, when you create output documents.

Michael Jones: +1 to Justin’s characterization of Input Documents and Output Documents.

Justin Richer: This group should treat all artifacts as something that is created by this group. As an official artifact.

Manu Sporny: hrm, that’s not true – why do CGs at W3C have FCGR and IPR commitments, then?

Justin Richer: You have to treat the documents that are created here as brand new documents that are taking some if its contents from other sources.

Dmitri Zagidulin: would this topic of discussion be a question for Ivan?

Michael Prorock: from the Publ WG “Input Documents: The following documents will be considered by the Working Group as inputs to the specifications to be developed.”.

Justin Richer: There must be misunderstanding if there back channel comments.

Justin Richer: yes, CGs have IPR commitments for their output documents.
it’s exactly the same.
this is not in contradiction to what I’ve said.

Ted Thibodeau Jr.: In my world the reason to list input documents is to tell people that we have taking into account various input documents. We are aware of standards from IETF that says whatever it says.
… It could contradict what we output, but we output it for a reason.

Justin Richer: +1 to TallTed.

Ted Thibodeau Jr.: There’s nothing there that gives IPR.

Michael Prorock: I did some querying, and in every case it’s defined very broadly.
… I really like the spirit of this PR.

Manu Sporny: To address justin_r ‘s point, I don’t know how many of you work with legal team when joining WGs.
… It is very important to those legal councils that. For example when CCG creates a specification that it goes through final specification agreement that requires IPR agreement, before it can be moved into an official group.
… This is a requirement for being used as an input document for a WG.
… Our legal counsel has made it clear that an input document needs prior IPR agreement.

Justin Richer: this is only true because you are pulling in text.
it’s not because it’s an “input document”, it’s because it’s going into the outputs.

Manu Sporny: Your statement was “IPR starts at the WG” – that’s not true… it starts before.
and it’s vitally important that it does.

Justin Richer: @manu I believe that is a mis-characterization.

Manu Sporny: I’d like to hear that from your legal counsel, justin_r :).

Markus Sabadello: I remember when the DID WG started, there was a previous specification in CCG, the DID Core specification, that was input document to the DID WG. at that time I remember the discussion about asking whether the GitHub history of it should be preserved when moving it into the WG.

Justin Richer: @manu you’ll hear from my lawyers ;).

Markus Sabadello: I think there was a lot of support for keeping the history. I think this means that the input document does not just inform the working group but is actually the basis of something the WG will take on to work on to create a deliverable.
… So in my mind I think input documents can be both, something to inform the group, but also could be a basis for an output document.

Kristina Yasuda: exactly, I think it can be both.

Brent Zundel: There is a difference in my understanding between input document listed in the charter, and a document the WG selects as FPWD of a deliverable they are working on.

Justin Richer: +1 those are very different.

Michael Prorock: the did-wg charter uses “input” in relation to documents in both ways - one informative, one to convert into an actual rec.

Brent Zundel: I think any documents that could become FPWD should be listed as input documents. But we shouldn’t conflate the two.
… Having something as input document doesn’t mean that the group takes it as FPWD. Theoretically we could use something else as FPWD as long as IPR is clean.

Proposed resolution: Merge PR 107. (Brent Zundel)

Brent Zundel: Going to run a simple proposal.

Michael Jones: +1.

Ted Thibodeau Jr.: +1.

Orie Steele: +1.

Justin Richer: +1 (this is a silly discussion).

Kristina Yasuda: +1.

Michael Prorock: +1.

Shawn Butterfield: +1.

Brent Zundel: +1.

Manu Sporny: -1 it doesn’t change what the WG does (but I will not object to the charter over it).

David Chadwick: 0.

Markus Sabadello: 0.

Charles Lehner: +0.

Dave Longley: 0.

Justin Richer: @manu it’s not meant to change what the WG does – which is what we’re saying.

Manu Sporny: -0.9 it doesn’t change what the WG does (but I will not object to the charter over it).

Ted Thibodeau Jr.: Some are citing experiences from last groups, others are citing legal counsels.

Resolution #1: (over the objection of Manu) Merge PR 107.

Ted Thibodeau Jr.: Member submissions need to have IPR. We could list Encyclopedia Britannica as input document. That would be silly. Listing a dozen input documents that do have influence, that’s entirely reasonable. Nobody outside the group needs to be involved.

Justin Richer: q.

Brent Zundel: With that I’m going to close issue 88.

Michael Jones: Microsoft has a very rigorous IPR process when chartering/joining WGs. None of what manu said applies at Microsoft. Input documents are not part of the discussion.

Brent Zundel: Thank you everyone for the conversation.
… I believe we constructed something good that is ready to take the next step.

2. Charter Proposal Finalization.

Brent Zundel: Please q+ to comment on proposal. It would be good to achieve unanimous support.

Proposed resolution: We will submit the VCWG Charter as it currently stands to the W3M and the AC for Review. (Brent Zundel)

Brent Zundel: +1.

Dave Longley: +1.

David Chadwick: +1.

Manu Sporny: +1.

Michael Jones: +1.

Kristina Yasuda: +1.

Ted Thibodeau Jr.: +1.

Orie Steele: +1.

Markus Sabadello: +1.

Michael Prorock: +1.

Dmitri Zagidulin: +1.

Charles Lehner: +1.

Aaron Coburn: +1.

Shawn Butterfield: +1.

Brent Zundel: Please indicate your vote if you’re on the call.

Resolution #2: We will submit the VCWG Charter as it currently stands to the W3M and the AC for Review.

Brent Zundel: I will talk to ivan to do the next steps.
… If we need to address concerns about the charter, I propose to leave the meeting on the calendar in case we need it.

Charles Lehner: 🎉.

Brent Zundel: Good work! I look forward to serving with you in the next WG.
… Any final words?

Manu Sporny: brentz you’re awesome, thank you for leading us through this!.

Dave Longley: +1 to brent’s awesomeness.

David Chadwick: +1.

Ted Thibodeau Jr.: +1MM :-).

Michael Jones: Seconding the appreciation of Brent.

Charles Lehner: +💯.

Brent Zundel: Thank you all.

Brent Zundel: zkim, end the meeting.

3. Resolutions