Proposal for Long-Term Non-Repudiation in DID:webplus Problem:

[cstoecker]

Problem:

DID:web, while convenient, faces significant auditability issues, especially regarding key rotations and DID document configuration events. Its centralized nature, lack of immutable history, vulnerability to tampering, dependence on web hosting providers, absence of native timestamping, and potential for data inconsistency pose challenges for ensuring long-term non-repudiation.

Importance of Long-Term Non-Repudiation:

Long-term non-repudiation ensures every piece of data remains transparent and immutable, establishing a clear, verifiable record. It is crucial for maintaining data integrity in regulated industries, impacting public trust, safety, and operational excellence.

Proposed Solution:

Integrate self-certifying identifiers with a robust microledger to enhance DID:web, including timestamping and sequencing of DID document configuration events. Store snapshots of this microledger on an immutable platform like “git” to counter deletion and duplicity attacks effectively.

Proposed Recipe:

1. Take snapshots of the microledger at regular intervals (e.g., every 15 minutes).
2. Store each snapshot in a git repository.
3. Ensure system resilience, even in scenarios like company bankruptcy.
4. Digitally sign each snapshot for added security.
5. Grant all partners and auditors access to the DID:web operator’s git repository (partners/auditors can do a git clone to replicate the DID doc histories)

This approach, adopted in Germany for compliance in regulated use cases (reference), ensures long-term non-repudiation and mitigates the aforementioned challenges faced by DID:web.

** Further Considerations: **

While KERI’s introduction of witness networks offers a more abstract approach for achieving long-term non-repudiation, its implementation can be more challenging compared to the proposed method. The git approach can be considered as one specific witness infrastructure. The combination of self-certifying identifiers and a robust microledger with a long-term non-repudiation instrument for DID:web transforms it into an auditable solution, ensuring tamper-proof timestamping and sequencing of DID document configuration events.

** Objective of the Issue **

Advance the DID:webplus method by proposing a solution for long-term non-repudiation, ensuring the integrity, transparency, and verifiability of data, and meeting the foundational requirements for compliance solutions.

I am happy to collaborate to refine and implement this solution with focus on non-repudiation, bringing DID:webplus to an operational readiness level by enhancing its security and functionality, and ensuring long-term trust, security, accountability, and operational excellence.

[cstoecker]

@vdods : I updated the broken link to the simple "long-term non-repudiation" solution in the text above. It is a pretty simple approach, but I think it is feasible for enhancing DID:web methods. We pretty much write the self-certifying identifier (SID) and its key event log to git. Did:web is used to discover did doc.

We have to do two things:

1. Define a mechanism to inform verifiers who resolve the DID:doc about the long-term non-repudiation git URL.
2. Define who has git access and who can read the SIDs and the key logs. Everyone or authorized parties? I think it shall be publicly available.

https://docs.verimi.de/openbanking/docs/qes/2.5/index.html#_long_term_non_repudiation

[vdods]

Thanks for the clear problem statement and solution proposal, Carsten.

The git approach is interesting, as it's a ubiquitous tool which allows the kind of full-history replication of data as needed here. In order for the periodic snapshot to capture all updates, I believe there would need to be a minimum validity duration for each DID document (so it can't change twice before the next snapshot), which would be totally reasonable.

I've been doing some design work on a functionally similar solution, which I'm calling (for now) a Verifiable Data Gateway (VDG -- in analogy to Verifiable Data Registry). The VDG would play the same role as the git snapshot, though it would use the same data model as the VDR itself in storing, indexing, and verifying all DID updates. This plays several roles:

• The VDG acts as a witness to the DIDs it tracks, verifying DID documents as soon as updates are made. This addresses the problem in which a VDR could alter a DID document.
• The VDG keeps a full copy of the microledgers of the DIDs it tracks. This addresses the long-term backup problem, the problem in which a VDR could delete a DID document in an attempt to repudiate a signature, as well as the service availability problem in which a VDR goes offline.
• The VDG can perform DID resolution on behalf of "light" clients, who simply need to issue a did:web-like HTTP GET to the VDG to retrieve the appropriate DID document, because they're trusting the VDG to do the DID tracking and verification for them. Furthermore, this reduces the DID resolution complexity to constant time (instead of having to retrieve and verify the full DID microledger). This will likely address some hurdles to adoption, because the heavier-weight the DID resolver, the tougher implementation and adoption will be.

There are potentially many VDRs (a person could even self-host a VDR).

But who runs a VDG? Here are a few reasonable scenarios:

• A company runs a VDG for the benefit of their users. Similar to other gateways that access some complex system on behalf of their users.
• A company is subject to some kind of regulatory audit, and therefore needs to have their own VDG to comply with the audits.
• A VDG could be run by some neutral entity, for example, the governing body of an industry consortium, and would be available to use by any member of that consortium.

What do you think?

[bumblefudge]

If you are assuming multiple VDGs that sync/replicate each other's data store of aggregated microledgers, that data store could use git, or ipfs, or any other replication-friendly data store (e.g., a CRDT, even some fancy NoSQLs) and they would essentially be building a VDR from all the DIDs they track. This creates feature parity with Sidetree (i.e. did:ion and did:element), which call their light clients "clients" and their VDGs "nodes" and their VDR a "sidetree" (actually closer to a CRDT than a layer-2 blockchain). The periodic hash-anchoring to a public blockchain is just an implementation detail, git-anchoring would qualify. Not that i'm advcocating for the extra work of making webplus explicitly conform to the sidetree spec, just saying there's prior art for this lightclient/heavyclient approach!

[vdods]

Note that I've included these concepts into the readme: https://github.com/LedgerDomain/did-webplus#long-term-non-repudiability-via-witnessing-schemes