Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Write an FAQ entry about why all dDIDs are anchored to the Bitcoin chain #167

Open
thobson88 opened this issue Jan 14, 2024 · 0 comments
Open

Comments

@thobson88
Copy link
Collaborator

Q: Given that the trust in downstream DIDs originates from the signature of the upstream entity (and not from a timestamp), why not store them completely off-chain?

A: There's no technical reason this shouldn't be done, and ultimately it's up to the user community to decide, but there are (at least) three major advantages to requiring all DIDs to be anchored to the Bitcoin chain:

1. Discoverability

If all relevant DID operations have an associated Bitcoin transaction, all users can be certain that they have a complete and up-to-date set of DID information, simply by iterating over the whole chain. As soon as a single alternative source is admitted, it is impossible to be certain that the aren't further, additional sources that are considered valid within the system but are not known to a particular user (unless some additional discovery protocol is introduced).

This is especially important with regards to DID revocation operations. If a DID is revoked, by publishing an update to a pre-existing DID document, but no reference is added to the Bitcoin chain, there is a risk that the revoked DID will continue to be accepted by some users.

2. Transparency

Upstream entities must remain in (joint) control of the downstream DIDs to which they have attested, else the privilege granted to downstream entities (in the form of their signed, valid dDID) may be abused. This requires that the upstream entity can easily find and scrutinise all dDIDs at all levels below their own DID.

In particular, the root entity (and others) will want to be able to compile a list of all published DIDs to understand the complete state of the trust network.

If DIDs can be published in multiple locations, there is a risk that some downstream DIDs may exist that are unknown to an entity upstream of they. Conversely, having a single source for all DID information ensures full transparency.

3. Simplicity

A common criticism of the W3C DID standard relates to the large number of DID methods that exist, threatening interoperability and requiring clients to support a large and changing list of specifications. These concerns disappear if all Trustchain operations are performed with the ION DID method (or another method targeting the same chain).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant