Re: Selective Disclosure for W3C Data Integrity

Hi Manu 

> What do you think of the above, Steve? Is it a reasonable way to
> proceed with this particular class of work in the VC ecosystem?

Yes indeed.  Thank you for your considered response. Agree that  It’s important to be clear about the business use case and therefore why this or that selective disclosure / selective redaction  mechanism is appropriate 

Regarding the size / cost volumetrics I don’t have concrete metrics but I’ll say it’s not uncommon for trade documents like invoices and waybills to have dozens or even hundreds of lines.  

Richards point is also very fair - although it is more of a change of business practice and so might be slower on uptake than the (admittedly less ideal) practice of just digitising the paper.  

We look forward to working with the community to develop quality fit-for-purpose specifications 

Kind regards 

Steven Capell
Mob: 0410 437854

> On 31 May 2023, at 6:20 pm, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> On Tue, May 30, 2023 at 12:03 PM Steve Capell <steve.capell@gmail.com> wrote:
>> I’d like to suggest that it can and should live alongside your selective disclosure specification because it serves a different use case
> 
> Yes, the reality is that there are a number of emerging selective
> disclosure/redaction schemes (DISD, SD-JWT, AnonCreds v2.0, JWP,
> di-bbs) and each one has its benefits and drawbacks. There is a risk
> that people in our community, and others, will prematurely jump in and
> start doing zero-sum "apples-to-oranges" comparisons between the
> different schemes... and it's easy to mislead, or be misled, about
> what these schemes can and can't do.
> 
> All that to say, I agree with you... these things should "live
> alongside" each other for long enough for proper implementation and
> analysis to be performed (years). I know people want all of this stuff
> to be done NOW, and some are rushing ahead and claiming that the
> problem is solved, but the reality we're seeing on the ground is that
> we're still early days with each of the approaches.
> 
>> [Singapore govt solution] serves a different use case
> 
> I can't speak directly to the use cases you cite without further
> study. We did look at the salted hash approach and the use of merkle
> trees for disclosures. Each had drawbacks that Dave outlined in his
> post (and we'll outline later in an attempt at a fair comparison
> between all the mechanisms). What would help us at this point is for
> each selective disclosure scheme to publish a mathematical model of
> some kind that lets you input total number of claims, number of
> mandatory claims, number of selectively disclosable claims, and a
> graph of how each changes based on those parameters. We have released
> something equivalent to this in our slide deck at the beginning of
> this thread. If we want to get to a fair comparison between the
> mechanisms, those things will have to be produced.
> 
>> - removing a small number of commercially sensitive fields from otherwise quite large trade documents.  It’s much more efficient for this
> 
> Hmm, do you have an analysis that you could share that helps us learn
> more about this? I'm not saying it's not true, I just don't have any
> way to analyze the "much more efficient" claim.
> 
> Assuming that what you're saying is true, creating a Data Integrity
> cryptosuite that does what you claim, and thus aligns w/ the W3C Data
> Integrity approach, is entirely possible. Not only that, but the
> design of Data Integrity is such that you are not forced to make an A
> vs. B decision. With Data Integrity, because of parallel signatures,
> you can choose A /and/ B. That is, you can issue a VC with parallel
> signatures - regular ecdsa-2019, ecdsa-sd-2023, and ecdsa-merkle-202x.
> We believe that this is one of the major benefits of Data Integrity --
> it doesn't put different approaches on collision courses with one
> another, as we saw with the VC-JWT, Gordian, and ACDC approaches
> (external signature approaches).
> 
>> - allowing any holder who is usually not the subject to redact.  This is important because it’s usually a party further downstream in the supply chain that wants to redact a bearer-token style credential received from upstream.
> 
> I believe your statement above (even though I haven't done the
> analysis). That's something we didn't design for in ecdsa-sd-2023, and
> it's unlikely to be something that we add (unless it's easy, which I
> doubt it will be). IOW, this might be the significant feature that a
> merkle-based approach provides (the ability to delete paths through
> the merkle tree as information is transmitted along the supply chain)
> that cannot be achieved with the other selective disclosure
> mechanisms.
> 
> In summary, I agree with you -- these things should live alongside for
> a while and deeper analysis on benefits and drawbacks is needed. I'll
> also note that Richard makes a very good point (that I'll try to
> respond to next) about re-thinking how these VCs might be created to
> reduce the need for cryptographic solution complexity. These selective
> disclosure mechanisms are more complicated than plain old digital
> signatures, so if we can simplify, we should.
> 
> What do you think of the above, Steve? Is it a reasonable way to
> proceed with this particular class of work in the VC ecosystem?
> 
> -- manu
> 
> -- 
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/

Received on Wednesday, 31 May 2023 08:48:20 UTC