- From: Christopher Allen <ChristopherA@blockstream.com>
- Date: Mon, 18 Sep 2017 19:57:34 +0000
- To: public-credentials@w3.org
- Message-ID: <CA+HTxFfUajHXUjPUUF+R9-TkEOxXvxaqh7vVPB1Qid7bKyVMPg@mail.gmail.com>
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 Monday, 18 September 2017 19:58:07 UTC