- From: Daniel Hardman <daniel.hardman@evernym.com>
- Date: Tue, 17 Sep 2019 16:02:52 -0600
- To: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Cc: Samuel Smith <sam@prosapien.com>
- Message-ID: <CAFBYrUqc-PaBzvoN3MiTsuX4kYofSW-CxzuOptmbyVa8e61msg@mail.gmail.com>
Sam Smith and I have been discussing an issue that I wanted to bring to this group. It is a risk that Sam has described as the "anybody can ledgerize" problem: *What is to prevent someone other than the owner of a DID from recording the initial version of a DID doc on a ledger, thus making public something that the owner intended to keep off ledger permanently or temporarily?* Even though this question is framed in terms of ledgers, it has direct application to non-ledger DID methods as well. I believe that some DID methods allow anyone with write permission or willing to pay transaction fees to write a DID and its initial DID Doc to the shared source of truth. Since the DID doc just contains public keys, all the info in it might be known by someone other than the DID's owner -- another party in the list of controllers, for example, or even an adversary. Yes, the adversary possesses none of the private keys, and so cannot control the DID after registration--but the mere registration of someone else's data under circumstances of an attacker's choosing could, in and of itself, constitute mischief. To guard against abuse, the correct behavior of a ledger is probably to require that the request to write the genesis version of the DID doc be signed by a key in the DID doc. Note that just signing the DID doc isn't enough, since the attacker could have captured the signature when he captured the DID doc content. Even better security would be to require that the DID value be *derived* from a key in the DID doc, and that the initial write request use that key as well. @Joe Andrieu <joe@legreq.com> perhaps this protection against abuse needs to be a rubric? Or perhaps it is more fundamental, and needs to be a requirement of all DID methods, period?
Received on Tuesday, 17 September 2019 22:03:37 UTC