updating algorithms-related reference documents for jwt-vcs

The issue was discussed in a meeting on 2022-03-30

List of resolutions:

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

View the transcript

#### 1.2. updating algorithms-related reference documents for jwt-vcs (pr vc-wg-charter#107) _See github pull request [vc-wg-charter#107](https://github.com/w3c/vc-wg-charter/pull/107)._ _See github issue [vc-wg-charter#88](https://github.com/w3c/vc-wg-charter/issues/88)._ **Brent Zundel:** This was raised by kristina. … Can you walk us through this? **Kristina Yasuda:** Addresses [issue 88](https://github.com/w3c/vc-wg-charter/issues/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](https://www.w3.org/2021/Process-20211102/). > See [W3C patent policy](https://www.w3.org/Consortium/Patent-Policy-20200915/). > 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](https://www.w3.org/2021/Process-20211102/) 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](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.

w3c / vc-wg-charter

updating algorithms-related reference documents for jwt-vcs #107