W3C home > Mailing lists > Public > public-credentials@w3.org > September 2017

Re: Verifiable Text-based Claims

From: Adam Sobieski <adamsobieski@hotmail.com>
Date: Wed, 20 Sep 2017 03:37:29 +0000
To: Christopher Allen <ChristopherA@blockstream.com>, "public-credentials@w3.org" <public-credentials@w3.org>
Message-ID: <DM5PR01MB3275CA64C6C732844CE45F00C5610@DM5PR01MB3275.prod.exchangelabs.com>

Thank you for the hyperlink to the cool project.

Imperviousness/resilience to censoring and overall ruggedness are design goals of the project(s) indicated at: https://w3c-ccg.github.io/verifiable-news/brainstorming.html , https://w3c-ccg.github.io/verifiable-news/sketchpad.html .

Design goals also include the reusability/portability of the system(s) to be specified across transport protocols. I could add some discussion and some examples which utilize magnet URI scheme. We could extend magnet to include the public key of the digital signature of described digitally-signed content (https://en.wikipedia.org/wiki/Magnet_URI_scheme#Parameters).

Best regards,

From: Christopher Allen<mailto:ChristopherA@blockstream.com>
Sent: ‎Monday‎, ‎September‎ ‎18‎, ‎2017 ‎4‎:‎04‎ ‎PM
To: public-credentials@w3.org<mailto:public-credentials@w3.org>

My concern with many revocation schemes is they are trivially censorable. A client asks if a claim has been revoked, and the attacker through any one of a number of man-in-the-middle methods says "no".

So then you might say "sign the responses" but these too are trivial to DOS. These also can leak privacy info as Joe has pointed out. The lesson from TLS cert revocation lists is that if they are not highly available users and developers will stop requesting.

I wrote up one very easy, highly available revocation method which checks to see if a Bitcoin address has been spent. Between massive p2p replication, multiple heterogeneous service and censorship resistant approaches like TOR, Bitcoin Fibre, and Blockstream Satellite, it is easy to see if a very has been revoked even if your network is being censored. See https://github.com/ChristopherA/revocable-self-signed-tls-certificates-hack

You can implement this hack easily today. The problem with this hack is that it doesn't scale well long term — it pollutes the UTXO database of Bitcoin. I do believe however that there are some other schemes using merkle trees with either sidechains or payment channels that may help address this.

As DIDs also use ledgers, and some special purpose ledgers like Sovrin & Veres are specifically written for verifiable claims, I would like DID method specs be able to also point to chain specific revocation approaches that are available to verifiable claims that use that chain for the DID.

-- Christopher Allen
Received on Wednesday, 20 September 2017 03:38:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:13 UTC