AW: RDF Dataset Canonicalization - Formal Proof

Dear Colleagues,

 

the construction we are talking about is based on Merkle Hash Trees and has been described in 

Bauer, David, Douglas M. Blough, and David Cash. "Minimal information disclosure with efficiently verifiable credentials." Proceedings of the 4th ACM workshop on Digital identity management. 2008, 

https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.153.8662 <https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.153.8662&rep=rep1&type=pdf> &rep=rep1&type=pdf 

 

It seems to be worthwhile to standardize this, as it would enable selective disclosure with 

standard crypto (e.g. ECDSA instead of BBS+, which is known to be at least a little less secure 

cf. https://link.springer.com/chapter/10.1007%2F978-3-662-53018-4_20).

 

BR,

Detlef

 

 

Von: Jeremy Townson <jeremy.townson@gmail.com> 
Gesendet: Sonntag, 28. März 2021 17:24
An: Tobias Looker <tobias.looker@mattr.global>
Cc: Christopher Allen <ChristopherA@lifewithalacrity.com>; Steve Capell <steve.capell@gmail.com>; Adrian Gropper <agropper@healthurl.com>; Alan Karp <alanhkarp@gmail.com>; Drummond Reed <drummond.reed@evernym.com>; Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials CG (Public List) <public-credentials@w3.org>
Betreff: Re: RDF Dataset Canonicalization - Formal Proof

 

> Sounds like a simple-minded cousin to ZKPs.

 

AFAIK, it is different from ZKP, but serves the same selective disclosure or redaction use-case. If a part of the document that one wants to hide is replaced with its hash, the overall document hash remains unchanged.

 

On Sun, 28 Mar 2021 at 04:56, Tobias Looker <tobias.looker@mattr.global> wrote:

> I’m a big fan of this approach, a form of redaction distinct from zk forms of selective disclosure.

 

> There was an attempt to spec one here in the CCG three-four years ago, but it died on the vine.

 

I'm also interested in learning more about this approach too, the questions I had last time were 

 

1. How the salt for each redactable statement would be managed in a way that would not leak the abstraction that "Linked Data Proofs" sets up. For example would the attached proof block have to have a long array of salts?

2. Proof sizes, having to have a salt per-statement signed as a part of the proof would significantly increase the size of the proofs representation.

3. Signature correlation, perhaps not important in this scheme, but I think the approach would require revealing a fixed signature regardless of which parts are redacted from the original proof?

4. Performance? Also perhaps a non-issue but if anyone has info/benchmarks around how the scheme might scale with the size of the data graph signed, that would be great to look at?

 

Thanks,


 <https://mattr.global/> 

 


Tobias Looker


Mattr


+64 (0) 27 378 0461
 <mailto:tobias.looker@mattr.global> tobias.looker@mattr.global



 <https://mattr.global/> 

 <https://www.linkedin.com/company/mattrglobal> 

 <https://twitter.com/mattrglobal> 

 <https://github.com/mattrglobal> 


This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

 

 

On Sun, Mar 28, 2021 at 3:49 PM Christopher Allen < <mailto:ChristopherA@lifewithalacrity.com> ChristopherA@lifewithalacrity.com> wrote:

On Sat, Mar 27, 2021 at 7:22 PM Steve Capell < <mailto:steve.capell@gmail.com> steve.capell@gmail.com> wrote:

The Singapore government  <https://www.openattestation.com/> https://www.openattestation.com/ does this already . Version 3 is W3C VC data model compliant 

 

Each element is hashed (with salt I think) and then the hash of the hashed is the document hash that is notarised 

 

The main rationale is selective redaction (because the root hash is unchanged when some clear text is hidden). But I suppose it simplifies canonicalisation too...

 

I’m a big fan of this approach, a form of redaction distinct from zk forms of selective disclosure.

 

There was an attempt to spec one here in the CCG three-four years ago, but it died on the vine.

 

I’d be interested is seeing this spec & implementation. Any links?

 

— Christopher Allen [via iPhone] 





This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.