Re: [Agenda] W3C CCG 2024-05-07 - Parallel Signatures in Verifiable Credentials

On Mon, May 13, 2024 at 9:11 AM Julien Fraichot
<Julien.Fraichot@hyland.com> wrote:
> I’ve caught up with the recording and I’m left with some interrogations that were not addressed in the presentation

Anil had some good responses for why ECDSA-SD might not make a lot of
sense in a multi-signature situation. To be clear, you can selectively
disclose the same payload signed by two different signers using
ECDSA-SD, but I'm struggling to think of a common use case for that.
:)

> When deriving an ECDSA-SD credential for sharing with the verifier, the only proof part of the presented document is the ecdsa-sd proof, dropping all other potential parallel proofs.

In most cases that's true, though it's not a requirement. You can
selectively disclose a single payload using multiple ECDSA-SD proofs
that come from different signers, but as Anil said, the use cases for
doing that are a bit tenuous... lots of extra complexity for a
questionable payoff.

> could prove problematic if parallel proofs represent different individuals/issuers who signed the same document,

If by "problematic" you mean "more complex", then yes, but it's
supported by the technology today. You might get in trouble if you try
to mix ECDSA-SD with BBS (the first one uses linkable proofs, the
second one uses unlinkable proofs). I think the general advice we'd
give these days is: Don't do it, unless you really know what you're
doing.

> and more importantly so when the document holds a proof chain.

Mixing set signatures and proof chains, again, while technically
possible, is something you should probably stay away from. There seems
to be this desire to wrap business processes into the set/chain
signatures, and while it's possible, you should consider if there is a
better way (like running people through a process on a website that
collects multiple VCs and keeps track of state on the backend of who
has signed what instead of trying to shove some complex proof
set/chain logic into the proofs).

To strain an analogy - we can combine boat technology and car
technology together, humans have done this before and given us the
glorious "boatcar". It can go on land (kinda) and in the water
(kinda), but it's pretty complex to maintain and not very good at
doing either.

> Do we have to sacrifice privacy in both those cases and not use SD proofs?

You can combine ECDSA-SD proofs together, the question is: What's the
driving use case?

> It is said in the presentation that the verifier specifies which type of signature they accept.

Yep.

> However I just wanted to clarify that it remains the wallet’s responsibility to allow for SD derivation/proof type selection?

All roles have to support specific selective disclosure types:

* The issuer has to issue a proof that is SD-capable.
* The wallet has to be able to derive a presentation for an SD proof.
* The verifier has to be able to ask for and process a particular
presentation for an SD proof.

If any one of those roles doesn't support a specific type of SD proof,
you can't do an end-to-end SD proof... but that's true for any of
these proof types (ECDSA, EdDSA, BBS, etc.).

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/

Received on Tuesday, 14 May 2024 14:11:12 UTC