Simplify VCDI deliverable

[brentzundel]

Simplify VCDI description, fix draft status, add description of input documents

Signed-off-by: Brent Zundel brent.zundel@gmail.com

---

Preview | Diff

[msporny]

I'm a bit concerned that once we get into the WG, certain individuals might try to remove half of the cryptosuites in the list. I'm also concerned that we don't specifically call out that BBS+ and JWP can't be standardized w/o the proper IETF work needing to be performed at IETF. That said, I'm fine w/ this if we can get the rest of the WG to consensus on these items.

[kdenhartog]

Agree with @msporny concerns here that this change could be weaponized later, but I don't see any specific reasons that this change couldn't occur.

[iherman]

My only reservation is with the VC-JWT reference, because that is, in fact, part of the existing standard and, therefore, may be considered as part of the other deliverable. It is not an Input Document.

I am not sure how to formalize this in the charter, but we may want to say that this deliverable may also include part of the current Data Model spec being moved to this deliverable (and remove the reference from the list of input documents), with a possible reference to the JWT section.

[iherman]

I'm also concerned that we don't specifically call out that BBS+

I am not an expert, but any reason why this is?

[msporny]

I am not an expert, but any reason why this is?

Both BBS+ and JWP require that cryptographic primitive work is performed at IETF and standardized before we can package up the primitives into a W3C cryptosuite. Without that work being completed, we are not going to be able to normatively reference the appropriate cryptographic primitives in IETF RFCs. The previous text in the charter mentioned this concern, the current text in this PR doesn't. It is understood by all, I hope, that if we don't have the IETF RFCs to base the BBS+ and JWP work off of, that we won't be able to publish anything at W3C that normatively standardizes BBS+ and JWP usage.

[msporny]

My only reservation is with the VC-JWT reference, because that is, in fact, part of the existing standard and, therefore, may be considered as part of the other deliverable. It is not an Input Document.

I think the goal here is to extract the VC-JWT section out of the VCDM spec and make it a standalone REC-track spec (just another cryptosuite-like spec) in order to make the VCDM spec cleaner.

[iherman]

My only reservation is with the VC-JWT reference, because that is, in fact, part of the existing standard and, therefore, may be considered as part of the other deliverable. It is not an Input Document.

I think the goal here is to extract the VC-JWT section out of the VCDM spec and make it a standalone REC-track spec (just another cryptosuite-like spec) in order to make the VCDM spec cleaner.

I understand that. But, to avoid any issues during review, we may want to make that clear because, again, that is not really an 'input document', like the others are.

[OR13]

This PR addresses the concern I raised here: #54

[OR13]

A nit to be cleaned up later, but I think ul / li would be more readable than a comma separated list.

[msporny]

I understand that. But, to avoid any issues during review, we may want to make that clear because, again, that is not really an 'input document', like the others are.

Yes, agreed. Although, I'm struggling to think of language that would clarify. My expectation is that no one will really catch on to this nuance (and if they do, it's easily explainable and shouldn't result in a Formal Objection).

To put it another way, this PR removes the nuances that we had in the previous text... and that's probably a good thing. We don't want people quibbling over nuances because, ultimately, nuances are up to the WG to evaluate... not the Advisory Council. :)

[selfissued]

I believe that removing the references to some of the potential input documents, such as JWP, moves us in the wrong direction. Please update this PR to restore them. Thanks.

[Sakurann]

I am a little concerned that there are multiple layers being mentioned without clarification of how they relate to expressing "proofs of integrity" - containers (JWTs, JWPs, etc), algorithms (BBS+, etc.), and concrete curves (secp256k1, ED25519, etc.)...

[msporny]

Yeah, agree with @Sakurann ... we might want to be specific about the layers:

• Container Formats
  • Data Integrity
  • VC-JWT
  • VC-JWP
• Cryptosuites (a fair number of these can be mapped to an input document)
  • JWS
  • EdDSA
  • NIST ECDSA
  • Koblitz ECDSA
  • NIST RSA
  • BBS+
  • PGP
  • GOST DSA
  • SM9 IBSA

Cryptographic algorithms and primitives are only to be taken from IETF and other standards organizations (e.g., SECG, X9, etc.)

[OR13]

the word "Cryptosuites " is somewhat misleading...

"JWS" supports "EdDSA + NIST + Koblitz" ...

"PGP" supports "EdDSA + NIST + Koblitz" ...

[OR13]

• https://github.com/openpgpjs/openpgpjs#performance
• https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms

[msporny]

JWS is a "kitchen sink" cryptosuite -- it includes everything (except, of course, for the things it doesn't... like GOST, SM9, BLS, and secp256k1 for over a decade). :)

[kdenhartog-mattr]

Just want to call out that if we believe key formats should be tied to container formats and cryptosuites than I think we'll need to add those to the list. Although I'm personally in favor of not defining them here and relying on key conversion techniques so that an X.509 cert or a JWK set published as a resource on the web, or a DID Document with verification methods could all be used with the same cryptosuites or container formats and key formats remain an implementation considerations.

[msporny]

Hrm, I missed this during the first go-around. We do have an input document here for the "Verifiable Credential Data Integrity 1.0" document... and that is the "Data Integrity" specification. We don't want to re-litigate that (as it took many months to do it last time). We may want to go with @Sakurann's suggestion below... which is to clearly articulate the draft documents at each layer. More below...

[mprorock]

I would like to ensure that we retain direct links to exactly what we are talking about - ok with categorization as suggested by @msporny

[OR13]

I'd be ok loosing the links and then adding them back... I would object to the charter in its current form or after this PR... it still needs a lot of work... I think we should try to merge things a bit faster and this section will probably needs good amount of cleanup before it becomes acceptable.

[selfissued]

Per discussion on the 16-Feb-22 working group call, please do not merge this until the references that it currently deletes, such as JWP, have been restored. Thank you.

[iherman]

The issue was discussed in a meeting on 2022-02-16

• no resolutions were taken

View the transcript

4.3. Simplify VCDI deliverable (pr vc-wg-charter#76)

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

Brent Zundel: this PR attempts to clear up draft status. apologies to recent comments..

Manu Sporny: Christina raised a comment that is good to focus on.
… we should call out the categories. i made an attempt to do that..
… two categories: container formats.
… second category: cryptographic suites..

Kristina Yasuda: thank you, Manu.

Manu Sporny: we're not talking about a mishmash of documents that will be squished in to one document..

Michael Jones: added an issue comment that this pull removes references to work items..

Manu Sporny: +1 to selfissued , we do need to come back in and re-add stuff after the refactoring..

Michael Jones: if we're going to consider this pull we should undo removing references.

Michael Prorock: +1 selfissued - we really want JWS explicitly called out based on DID WG experiences.

Kyle Den Hartog: Manu's categories. key formats. will define whether we want these cryptosuites to fit the keys in. are we choosing key formats?.

Kristina Yasuda: +1 to general restructuring.

Manu Sporny: +1 to Mike Jones. important things have been removed. this is a restructuring and we'll add the references back in later..

Kristina Yasuda: and +1 to Kyle's comment on key formats.

Michael Prorock: +1 restructuring good - but i do not want stuff pulled until we know how it is coming back in.

Brent Zundel: state specific feedback. keep engaging. consensus seems net-more..
… see you in a week.

---

[iherman]

The issue was discussed in a meeting on 2022-02-23

• no resolutions were taken

View the transcript

4.5. Simplify VCDI deliverable (pr vc-wg-charter#76)

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

Brent Zundel: the VCDI deliverable description was becoming messy... this PR simplifies the text... its a step towards the refactoring Manu does in his PR.
… I suggest merging 76 and then 77..
… and then try and add remove or move items..
… feedback on suggestions?.

Manu Sporny: +1 to that approach, I like the simplification, and the list approach..
… its a good restructuring, the next PR 77 presumes that this is merged..

Michael Jones: I commented on 76 some weeks ago asking for the deleted spec references to be restored.
… I am fine once deleted references are restored, and I am not ok merging this without that.

Michael Prorock: +1 mike jones.

Brent Zundel: its not intentional deletion, I was not sure how to include JWP, PR 77 adds it back in the correct place.

Michael Jones: I would prefer that each PR does no damage.
… do one thing well.

Brent Zundel: simplest route forward would be for you to suggest were JWP should go..

Michael Jones: it should be listed in non normative deliverables.

Manu Sporny: can you make that change?.

Michael Jones: i don't know how to edit other peoples PRs.

Brent Zundel: PR 76, we want to make sure JWP is listed in this PR under.... non normative deliverables?.

Manu Sporny: JWP should be listed under deliverables assuming IETF progress.

Brent Zundel: lets look at 77.

Manu Sporny: we responded to you in PR 77.

Kristina Yasuda: can i talk about 77?.
… 77 seems to do more than just restructuring, because it adds a new section.
… I don't understand the new section.
… there is a comment about, ... , is it in scope to work on data integrity draft?.
… we can't tell exactly what is going on.

Michael Jones: as I just said, can we please fix the problems in 76, and then consider that independent of other PRs.

Manu Sporny: the reason is that brent's simplification takes it out.

Michael Jones: why not put it back in the PR?.

Manu Sporny: because brent's PR deletes that section.
… 77 tries to add that stuff back in under a a section.
… if we undo everything that brent did, we can add JWP back in.
… 77 takes brents PR and then separates what kristina is getting at.
… and then adds a section for conditional normative deliverables.
… we can't do what you are asking.

Orie Steele: I believe we are all in agreement about the changes that we want to see. We want to see 76 merged, and we want to see 77 merged. We can't add VC-JWP back into 76 because of what Manu said. We need to clarify what we mean by conditional deliverables in PR 77..
… Although these PRs are not perfect, it would be much better to merge 76, then merge 77, then raise new PRs to fix any issues created. The structure that we have today is not great, we can't do what Mike's asking w/ 76 because the structure has to be fixed..
… Then we need to make additional changes because of the conditional changes... My main point, we need to get to the point of merging 77, this is a new section, Kristina's concerns are valid, we need to move towards merging PRs..

Michael Jones: I understand what you are saying Manu, my intent is for you to put things back.
… I don't think 77 is ready to merge as is.
… this is not an appropriate use of our resources.

Manu Sporny: I proposed adding it back to the end of the sentence.

Michael Jones: there are other deletions.

Kristina Yasuda: I think Orie made a comment that "cryptosuite" term is somewhat misleading, with which I agree. For example, what does "BBS+ Cryptosuite" would cover. BBS+ low level primitives will be defined in IETF. than we define how to use it in data integrity deliverable. why separate conditional deliverables?.

Brent Zundel: those are still listed,.
… JWP is now added back... this should allow us to merge this.
… and then restructure.

Mahmoud Alkhraishi: i think if you look at the pr preview it'll alleviate the concerns.

Ted Thibodeau Jr.: are we ready to merge 76?.

Brent Zundel: I believe we are.
… anyone opposed to merging 76?.
… no objections, lets merge.