- From: Julien Fraichot <Julien.Fraichot@hyland.com>
- Date: Mon, 22 Jan 2024 14:50:26 +0000
- To: Manu Sporny <msporny@digitalbazaar.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <SA3PR13MB61882254B389C3714E478A4690752@SA3PR13MB6188.namprd13.prod.outlook.com>
Thanks Manu for the detailed answer, I’ve also been having a conversation with Dave Longley on the github repo so everything is clearer now. * Simple predicates can be done with static values. That is: "over age 15", "over age 18", "over age 21". Can you elaborate on this? Is that a built-in feature of the spec/implementation – or is it by returning a piece of data such as the Date of Birth, the verifier has to implement a computational check? Thans From: Manu Sporny <msporny@digitalbazaar.com> Date: Sunday, 21 January 2024 at 22:02 To: W3C Credentials CG (Public List) <public-credentials@w3.org> Cc: Julien Fraichot <Julien.Fraichot@hyland.com> Subject: [EXTERNAL] Re: Questions about ecdsa-sd-2023 CAUTION: This email originated from outside of Hyland. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Wed, Jan 17, 2024 at 8:51 AM Julien Fraichot <Julien.Fraichot@hyland.com> wrote: > As discussed privately with Manu I have a few questions about the ecdsa-sd-2023 crypto suite implementation and I thought having them on the public list could help others at least get those answered too, should they need it one day. Yes, great idea, Julien! Happy to try and answer what I can. Some other engineers from our organization might chime in on some details if I get something wrong, more below. > If the verifier asks for mandatory fields, it means that they should have quite a precise knowledge of the structure of the document, which might not always be the case, for instance in the case of a more universal verifier. Wouldn’t it make more sense to have the issuer specify what are those mandatory fields, through a property of the VC or its proof? When the base proof is created in ecdsa-sd, the issuer provides the list of mandatory disclosure fields to the Holder. The Holder knows if they don't always disclose these fields in the disclosure proof that the verifier will fail to verify the signature, specifically the signature over the mandatory fields. The Verifier doesn't have to know what they are or ask for them, if they are not provided by the Holder, the signature verification will fail. These "mandatory" fields aren't shared as paths in the document, but rather indexes for each canonicalized statement. Thanks to Greg Bernstein, there is a detailed example in the appendix that covers this topic. The mandatory fields are asserted here by the issuer: https://urldefense.com/v3/__https://www.w3.org/TR/2023/CRD-vc-di-ecdsa-20231227/*example-mandatory-pointers__;Iw!!C8mu0vCj!aMwZpFT_VpZljVLNaQrPWopMdXoEi6lvI8V1D3ETZTjJaOG7GWpGm4zaaO_IgIDLmdd-aTyPUrl5GBpyfTvENH1ZVZ8$<https://urldefense.com/v3/__https:/www.w3.org/TR/2023/CRD-vc-di-ecdsa-20231227/*example-mandatory-pointers__;Iw!!C8mu0vCj!aMwZpFT_VpZljVLNaQrPWopMdXoEi6lvI8V1D3ETZTjJaOG7GWpGm4zaaO_IgIDLmdd-aTyPUrl5GBpyfTvENH1ZVZ8$> and then they are encoded in the base signature here and given to the holder: https://urldefense.com/v3/__https://www.w3.org/TR/2023/CRD-vc-di-ecdsa-20231227/*example-add-base-signing__;Iw!!C8mu0vCj!aMwZpFT_VpZljVLNaQrPWopMdXoEi6lvI8V1D3ETZTjJaOG7GWpGm4zaaO_IgIDLmdd-aTyPUrl5GBpyfTvE_pASit4$<https://urldefense.com/v3/__https:/www.w3.org/TR/2023/CRD-vc-di-ecdsa-20231227/*example-add-base-signing__;Iw!!C8mu0vCj!aMwZpFT_VpZljVLNaQrPWopMdXoEi6lvI8V1D3ETZTjJaOG7GWpGm4zaaO_IgIDLmdd-aTyPUrl5GBpyfTvE_pASit4$> When the holder derives a proof, they tell the verifier which indexes (in the canonicalized document) are mandatory and which ones are selective disclosures: https://urldefense.com/v3/__https://www.w3.org/TR/2023/CRD-vc-di-ecdsa-20231227/*example-derived-group-indexes__;Iw!!C8mu0vCj!aMwZpFT_VpZljVLNaQrPWopMdXoEi6lvI8V1D3ETZTjJaOG7GWpGm4zaaO_IgIDLmdd-aTyPUrl5GBpyfTvERhQu3f8$<https://urldefense.com/v3/__https:/www.w3.org/TR/2023/CRD-vc-di-ecdsa-20231227/*example-derived-group-indexes__;Iw!!C8mu0vCj!aMwZpFT_VpZljVLNaQrPWopMdXoEi6lvI8V1D3ETZTjJaOG7GWpGm4zaaO_IgIDLmdd-aTyPUrl5GBpyfTvERhQu3f8$> What this does is allow the verifier to receive a VC that looks like any other VC, canonicalize it, and then determine which statements go into the "mandatory disclosure proof" and which statements have individual selective disclosure proofs on them. So, to answer your question, the verifier doesn't need to know what the mandatory fields are (they will get them and they can't verify the selectively disclosed VC without them). For the selectively disclosed fields, they just need to know what field they need (they don't need to know about any of the other selectively disclosable fields). > When selecting the fields to disclose, I understand this would be the responsibility of both the holder (from the user perspective) and the wallet (for the technical action of doing so). There is an example of what the verifier might ask to disclose to the holder, but contrary to the BBS+ suite where the reveal document serves of some kind of binding contract to the disclosed data, here it seems entirely up to the holder to choose which properties to disclose. So, at that point, how can we “automate” the verification, to make sure the actual requested data is disclosed without human intervention (which would imply reading a JSON file basically)? Hmm, when you say BBS+, are you referring to only the IETF work on the primitives, the old BBS cryptosuite, or the new one? :) The new one (bbs-2023) works like ecdsa-sd-2023, so you can reason about it in much the same way. > Why isn’t it possible to verify the initially signed full VC when signed with @digitalbazaar/ecdsa-sd-2023-cryptosuite? It's possible, but it's not necessary. Either the disclosure proof verifies or it doesn't. The only way you can create a disclosure proof is if you have a valid base proof. If you want to see if you have a valid base proof, one way to do it is to generate a selective disclosure proof for all the mandatory statements, and then one for each selective disclosure statement. Doing so is largely unnecessary unless you're debugging your implementation. One other concern that we had was that people would accidentally confuse base proof verification with disclosure proof verification. So, if we included an algorithm for base proof verification, someone might accidentally think that their implementation should be sending the base proof to the verifier (which it definitely shouldn't be doing). By NOT specifying that algorithm, any system that accidentally forwards a base proof is far more likely to result in a verification failure at the verifier (followed by a bug being reported and the implementer fixing their implementation). > Is support for predicates envisioned for this spec? Simple predicates can be done with static values. That is: "over age 15", "over age 18", "over age 21". Range predicates are not supported, such as "bank account balance greater than 10,000". We are unlikely to support range predicates in this version of the spec unless someone has a really good idea on how to accomplish it w/ ECDSA /and/ is willing to coordinate multiple implementations, add to the test suite, and convince the WG that it's worth going through another Candidate Recommendation phase to do so. :) -- it's possible, but unlikely at this point in time. > I didn’t quite understand the reasoning behind the blank node ids? Looking at this example https://urldefense.com/v3/__https://w3c.github.io/vc-di-ecdsa/*example-canonical-hmac-document__;Iw!!C8mu0vCj!aMwZpFT_VpZljVLNaQrPWopMdXoEi6lvI8V1D3ETZTjJaOG7GWpGm4zaaO_IgIDLmdd-aTyPUrl5GBpyfTvE11p9OKg$<https://urldefense.com/v3/__https:/w3c.github.io/vc-di-ecdsa/*example-canonical-hmac-document__;Iw!!C8mu0vCj!aMwZpFT_VpZljVLNaQrPWopMdXoEi6lvI8V1D3ETZTjJaOG7GWpGm4zaaO_IgIDLmdd-aTyPUrl5GBpyfTvE11p9OKg$> , is the goal just to obfuscate the _c14n indexes so one wouldn’t be able to guess the structure of the original document? Yes, exactly. Certain selective disclosure schemes, such as SD-JWT, leaks information based on the document structure (unless you proactively know to add decoys to the data). For example, if you have an array of "children", you don't want the size of the array or the array position to leak information. ecdsa-sd avoids this problem by obfuscating any blank node id so that you don't know how many members might be in any particular set. That's what the HMAC operation on the indexes does. It protects set information w/o having to have application-specific knowledge of the data structure being decoyed. > Otherwise thanks as always to the Digital Bazaar team for the spec and open sourcing of the solution. Thanks for looking over all of this, Julien. Let us know if we can help further! :) -- manu -- Manu Sporny - https://urldefense.com/v3/__https://www.linkedin.com/in/manusporny/__;!!C8mu0vCj!aMwZpFT_VpZljVLNaQrPWopMdXoEi6lvI8V1D3ETZTjJaOG7GWpGm4zaaO_IgIDLmdd-aTyPUrl5GBpyfTvEjzn5k_4$<https://urldefense.com/v3/__https:/www.linkedin.com/in/manusporny/__;!!C8mu0vCj!aMwZpFT_VpZljVLNaQrPWopMdXoEi6lvI8V1D3ETZTjJaOG7GWpGm4zaaO_IgIDLmdd-aTyPUrl5GBpyfTvEjzn5k_4$> Founder/CEO - Digital Bazaar, Inc. https://urldefense.com/v3/__https://www.digitalbazaar.com/__;!!C8mu0vCj!aMwZpFT_VpZljVLNaQrPWopMdXoEi6lvI8V1D3ETZTjJaOG7GWpGm4zaaO_IgIDLmdd-aTyPUrl5GBpyfTvEI-hFPwY$<https://urldefense.com/v3/__https:/www.digitalbazaar.com/__;!!C8mu0vCj!aMwZpFT_VpZljVLNaQrPWopMdXoEi6lvI8V1D3ETZTjJaOG7GWpGm4zaaO_IgIDLmdd-aTyPUrl5GBpyfTvEI-hFPwY$> ----------------------------------------- Please consider the environment before printing this e-mail ----------------------------------------- CONFIDENTIALITY NOTICE: This message and any attached documents may contain confidential information from Hyland Software, Inc. The information is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for the delivery of this message to the intended recipient, the reader is hereby notified that any dissemination, distribution or copying of this message or of any attached documents, or the taking of any action or omission to take any action in reliance on the contents of this message or of any attached documents, is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail or telephone, at +1 (440) 788-5000, and delete the original message immediately. Thank you.
Received on Monday, 22 January 2024 14:50:39 UTC