algorithms-related input documents for all proofs of integrity types #88
Comments
No, that would be a mistake, and lead to confusion. The way this ecosystem has evolved over the past many years looks like this: DIF and W3C CCG Drafts refer to IETF crypto. W3C input documents refer to CCG Drafts / DIF / any document on the internet. These drafts are actually doing stuff... that is not handled by IETF, so you cant just replace them. The purpose of the WG referring to input documents is to respect where the work has started, but the wg can do whatever it wants, regardless of what the CCG says. DIF does the same thing.
|
Yes, but only in the context of one of the proofs of integrity.
Yes, and it does so for both JWT and LDP
I get that, the current input documents just seemed disproportionate. We probably don't need to reference all the underlying crypto documents that JWS depends upon since it will be a long list, but might be good to have some of the documents below. https://datatracker.ietf.org/doc/html/rfc7518 |
|
I am concerned about overloading the charter with every possible input document. |
Definitely not. An input document is something the group takes over and puts on the W3C REC track. W3C has no authority to take an IETF RFC as input and put it on the REC track. Any document that is already an IETF RFC can be referenced, normatively, from any specification that the VC2WG will work on. There still seems to be a fundamental misunderstanding on what an input document is, what an IETF RFC is, and how the WG will work with those types of documents. |
|
I would be fine accepting this list of RFCs as input documents relevant to VC-JWT... https://datatracker.ietf.org/doc/html/rfc7519 Also many of them are relevant to JsonWebSignature2020. But it's not correct to say they should replace CCG docs which are currently present. They do different things. |
|
Could we keep CCG input documents as-is and add (all or parts of) above RFCs suggested by Orie as additional reference documents? |
The way this is typically done is that those normative references would be included in the JsonWebSignature2020 document (which is an input document to the VC2WG). |
|
@msporny yes, but that assumes that those RFCs are somehow not relevant to VC-JWT... which seems wrong... Not a hill I would die on, but.... seems worth it to be exhaustive in input documents given they are an entry point for "getting up to speed". |
Any document that depends normatively on IETF RFCs can reference IETF RFCs. So VC-JWT can reference them as well.
IETF RFCs are not input documents. :) |
|
The issue was discussed in a meeting on 2022-03-23
View the transcript2.8. algorithms-related input documents for all proofs of integrity types (issue vc-wg-charter#88)See github issue vc-wg-charter#88. Brent Zundel: algorithms-related input documents for all proofs of integrity types. Kristina Yasuda: This data is whether we want to add additional RFC input documents for VC-JWT work.
Manu Sporny: JWS will reference the RFCs. VC-JWT should do so as well.. Brent Zundel: If there was a theoretical PR, would people be opposed to merging it.. Orie Steele: I would be in favor of a PR adding the RFCs relative to VC-JWT.. Kristina Yasuda: I would be glad to do that.. Michael Jones: I had a practical question, are there RFCs not transitively referenced by JWS or some of the other JOSE related input documents that we should be adding because there isn't a transitive reference to them?. Manu Sporny: The answer to Mike's question is that I don't think there are documents not transitively referenced.. Orie Steele: I queued to answer Mike's question about transitive reference.. Manu Sporny: The input document to VC-JWT is defined in the VC 1 spec.
Manu Sporny: It contains normative references to the JOSE specs. I don't see the problem here..
Michael Jones: Since there aren't input documents other than previous version of our own specification, I would support WG considering a PR to do so, probably authored by Kristina and approved by Orie.. Brent Zundel: We have an input document, which is the previous version of the specification..
Kristina Yasuda: My suggestion would be to explicitly add a sentence saying that the previous specification is an input document for the VC-JWT work..
Brent Zundel: There is a link in the charter..
Kristina Yasuda: Can I have a few days to investigate?.
Brent Zundel: I am fine with that course of action.. |
|
addressed by PR, closing |
|
The issue was discussed in a meeting on 2022-03-30 List of resolutions:
View the transcript1.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. Kristina Yasuda: Addresses issue 88. For the cryptosuites we are only referencing CCG documents which define algorithms. 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. 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. 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.
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.
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.
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".
Kristina Yasuda: It's to clarify the documents that we would look into when we work on JWT VCs.
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.
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.
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. Michael Jones: There was a suggestion in chat to say "input documents include...". I'm fine with this clarification.
Michael Jones: Defining terms such as "input documents" is going too meta for me. The English meaning is clear enough.
Justin Richer: I wanted to provide a quick definition what input and output documents mean.
Justin Richer: This group should treat all artifacts as something that is created by this group. As an official artifact.
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.
Justin Richer: There must be misunderstanding if there back channel comments.
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.
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. Manu Sporny: To address justin_r 's point, I don't know how many of you work with legal team when joining WGs.
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.
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.
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.
Brent Zundel: I think any documents that could become FPWD should be listed as input documents. But we shouldn't conflate the two.
Brent Zundel: Going to run a simple proposal.
Ted Thibodeau Jr.: Some are citing experiences from last groups, others are citing legal counsels.
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.
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. |
Currently suggested input documents in PR #77 are all CCG documents, which define Signature Algorithms such as EdDSA, ECDSA only for Linked Data Proofs, which is not the only proof of integrity for the vc-data-model. IETF documents should replace CCG documents or be added as input documents.
The text was updated successfully, but these errors were encountered: