Clarify proof mechanism and algorithm selection #584
Conversation
* Disambiguate 1EdTech conformance certification from experimental or coordinated usage * Update implementation guide * Spelling corrections in affected page sections.
|
Great improvements Nate! It's been a while since I participated in the discussions, and was a little confused by the section on Achievement.id DataURIs. Maybe the Implementation Guide could be updated to explain why one would use a DataURI. Section 3.1.3 does not mention it. |
|
@andyfmiller about the data URIs mention in the diff, sorry that's unrelated to this PR. I did correct a few spelling errors that I found while doing this work, and my editor rewrapped some lines on save, and I missed reverting that one. I'll take another look and make sure to remove extraneous changes in a second commit. |
|
The primary concern here is that the to use a verifiable credential linked data proof or data integrity method the current spec says you MUST use the EdDCA cryptographic proof. However, that proof method while relatively simple, also exposes the credential to potential identity discovery through linking the paths that a credential follows (issuer to credentialSubject; holder to relying party, e.g., employer; and relying party to verifier). It's a core design tenet of the VC ecosystem to try where possible to build unlinkable credentials so that discovering the identity of a credentalSubject, or an issuer, or a relying party is simply not possible. There are crypto suites the offer this. For VCDM v2.0, the one most robust in its capabilities is BBS, now a part of the recommended data integrity options for VCs. For some use cases unlinkability may not be important. But for many it is. Two examples from the BBS spec illustrate these two circumstances. I understand that it quickly becomes awkward to build conformance tests for all the approved VCDM v2.0 linked data proofs. We do want to support commemorating compliance so that effort must not require herculean effort. But we also want to support use cases where discoverable identity needs to be prevented. One option is to do what the Federal Government has done. The Feds require that official business using verifiable credentials must demonstrate compliance with their security guidelines, even though those guidelines do not represent the current state of the cryptographic arts. The work around, sanctioned by the US Gov, is to demonstrate compliance with a signature method within the suite of those required, but allow use of another signature method in practice. This 'dual signature' approach allows them to say the credential adhered to the mandated requirements, but the alternate proof can be used in real world applications. In our case, that is, for 1Edtech's case, one could have a conformance test that uses EdDSA in order to demonstration the required guidelines have been met and enable the issuance of a 1Edtech endorsement of compliance. We could also indicate that there are a suite of tested VCDM v2.0 compliant data integrity suites for linked data proofs that implementers should be able to select among for their use cases. If unlinkability is among them, then BBS is appropriate for them. Whether we formally require that the credentials are dual signed our not is entirely up to 1Edtech. I'd suggest that dual signature is not needed in actual implementation. The recommendation here would be we make the EdDSA necessary for conformance testing, but we allow any of the designated data integrity suites that are compliant with the VCDM v2.0 specification. The Implementation Guide can then elaborate more about those options. For those interested in the details of BBS, a presentation that Greg Berstein did for the NIST Crypto Reading Club back in October 2023 has a thorough elaboration of it, including for the math nerds a follow up section on the math used (not for the faint hearted ;-)) |
|
Perhaps a tweak to the spec page is necessary to distinguish conformance testing requirements vs general flexibility (in the same vein as what Nate did with the practices file). I will note though that BBS is in a draft state, and by 1EdTech policy it should not be referenced/used in this spec until it becomes final itself. |
|
+1 approve this PR. |
Phil alerted me that we may have left some things about securing mechanisms and how they may evolve over time unclear. I've taken a stab at clarifying what is required for conformance, and how experimental forward-looking usage of additional cryptosuites may evolve and eventually be recommended by the workgroup for inclusion in the conformance suite and core spec itself, given that 1EdTech confirmed prior to finalization that it may be possible to allow additional cryptosuites as an errata-level change (not rising to the level of a new chartered minor spec version).