w3c-ccg
Define a mechanism for auditability / change tracking
The read mechanism does not provide any sort of auditability on the DID, which leaves this DID Method open to insider-threat attacks, among others.
(I'm sure there are more grown-up (less single-service-dependent) ways to do this, but we could start by snapshotting the DID doc with archive.org :smile: )
~~+1. I think the proposal so far is to add KERI-like mechanisms (a chain of backwards hashlinks, plus outside observers).~~
+1. I think the proposal so far is to add KERI-like mechanisms (a chain of backwards hashlinks, plus outside observers).
We need to be careful here. This is insufficient if the chain can be severed/reset back to some point in the past and continued from there.
+1. I think the proposal so far is to add KERI-like mechanisms (a chain of backwards hashlinks, plus outside observers).
We need to be careful here. This is insufficient if the chain can be severed/reset back to some point in the past and continued from there.
Isn't that true of any DID Method that's based on a blockchain as well? For example by producing a longer chain on BTC that invalidates a BTCR update and the new longest chain includes a different update then it would be susceptible to this too. The tradeoff between conducting this attack on BTCR vs did:web is the feasibility of the attack. In the case of an external adversary on did:web they compromise the server/resolution to conduct this attack. On BTCR they have to attack the entire chain, but both are theoretically possible.
The main difference in my mind is that the Server admin (who could also be the DID Controller) has an easier time to do a revision if they wanted to do that (just as they could without any mechanism).
@kdenhartog,
Isn't that true of any DID Method that's based on a blockchain as well? For example by producing a longer chain on BTC that invalidates a BTCR update and the new longest chain includes a different update then it would be susceptible to this too.
First, not every blockchain works that way, some have consensus with finality of 1 instead of some lower probabilistic finality. Second, this is about roots of authority. Either the DID method allows the DID controller to change history without detection (bad), another single party (such as the domain controller in the case of did:web) can change history without detection (bad), or there's some combination of immutable history and/or community dispersed authority/transparency to see changes. The blockchain-based methods generally offer something in this last category while did:web currently does not, falling into at least one of the first two categories.
The tradeoff between conducting this attack on BTCR vs did:web is the feasibility of the attack. In the case of an external adversary on did:web they compromise the server/resolution to conduct this attack. On BTCR they have to attack the entire chain, but both are theoretically possible.
Yes, both are theoretically possible but no where remotely near the same difficulty. Also, the BTCR protects against insider attacks, putting insiders into the same boat as any other attacker, whereas did:web gives them special privileges. This part is not the same. I see you mention this next:
The main difference in my mind is that the Server admin (who could also be the DID Controller) has an easier time to do a revision if they wanted to do that (just as they could without any mechanism).
Yes.
@dmitrizagidulin,
would that not be addressed by outside observers?
Yes, but we can't just hand wave. We need to build into did:web's protocol how that observing is done/how observers are chosen and checked -- how observer consensus works (or doesn't/error margins), etc.
I suggest we close this issue, the complexity is not worth it, and there are other DID Methods with better audit-ability for this use case.
+1, I'd venture to guess because the controller and host are collapsed in this system in a way that allows them to collude with out detecting it there's no way that this ends up working properly and any solution will be subvert-able when that case is true.
As an aside, if somebody did want to do this, HTTP has had support for validation of content by hash for quite some time.
One could specify that entity tags be some reliable hash, and write them to some blockchain. (The underlying specification is silent as to how entity tags should should be calculated, but SHA1 over the content is commonly used. One could specify something more modern if desired.)
Doing this, though, begs the question of diversity among implementations.
https://datatracker.ietf.org/doc/html/rfc7232#section-2.3