Re: [EXTERNAL] Re: Questions about ecdsa-sd-2023

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.