RFC 0289: The "well-known DID" problem (a.k.a. roots of trust)

[SvenHammann90]

First of all, the Trust-over-IP RFC has clarified many concepts for me that I have previously only had a "half-understanding" of, so thanks a lot to all contributors.

There is still one rather fundamental issue that I believe warrants more discussion. I am not sure whether the TOIP RFC is the perfect place for this, but it seems to be closely related to the topic. (tl;dr at the end)

Let me illustrate the issue of "well-known DIDs" (or roots of trust) with an example:

Suppose a verifier wants to verify a verifiable credential that should only be given out by a certified medical doctor, such as a prescription [1]. A necessary part of verification is to check that the VC is valid with respect to an underlying governance framework. In this case, this means that there should somewhere exist a list of "authorized" DIDs that belong to certified doctor. How can I trust this list? It is probably signed by a public key that belongs to some "higher authority", such as a government agency authorized to certify doctors. However, how can I now obtain an authentic copy of this public key? The government agency has a public DID, but how do I know it? It might be posted by an even higher government agency. I am now following a chain not that unlike the certificate authority chains in the CA-based PKI used by TLS today.

In presentations by Drummond Reed, e.g., [2], (I paraphrase) he mentioned that you are supposed to follow this chain until you come across a DID that you recognize, a "well-known DID", so to speak. What does it mean that I recognize a DID? How would I, or my agent, recognize a supposedly "well-known" DID?

In the classical CA-based PKI, root certificates come pre-installed on browsers. Would such "well-known DIDs" come pre-installed on agents? Then I would have to trust the agent distributor, which I may not be comfortable with.

I realize that, at some point, I have to trust someone to tell me the correct DID. However, this issue becomes particularly tricky if I explicitly DO NOT want to trust the existing CA-based PKI used for TLS. In this case, I would NOT be able to trust information published on websites. I realize that this is a somewhat extreme setting, but the claim is sometimes made in the SSI community that a "decentralized PKI", which goes back to the beginnings of RWOT and is related to what is described here, would REPLACE the existing CA-based TLS PKI; meaning that I would NOT have to trust it.

If there exists, somewhere, a thorough write-up of the "well-known DID" topic, I would be glad if you could link me to it. If not, maybe the Trust-over-IP RFC would be a good place to write about this?

tl;dr: No matter what the governance framework, at some point I need to know some governance authority's public DID to verify any credential in the framework. How do I securely obtain an authentic copy of such a "well-known DID", especially WITHOUT falling back to trusting the existing CA-based TLS PKI? Should the Trust-over-IP RFC discuss this in more detail?

[1] https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/alice-attempts-abuse-verifiable-credential.md

[2] https://www.youtube.com/watch?v=L0wE7RWxc0M

Thanks for reading my long issue, Sven

[swcurran]

It's good question. We wrote a paper about this a long time ago that basically outlines the pattern you have noted above. There are ways to short cut the process using Credential Registries that aggregate information about the DIDs, which are much like CAs, with the major difference that they would be operated by (or for) the source of authority for the domain.

How is it different from a CA? With a CA, you have no information about the due-diligence done by the CA about the data asserted by the certificate holder. There are thousands of CAs with different levels of trust. For the most part, all you are trusting is the enabled encryption, and whether you recognize and trust the well know DNS name. Getting a verifiable credential from a trusted source (even if that means traversing several sources) with authority in the domain (e.g. education) has more value than a set of self-asserted claims that are included as part of buying a generic certificate from a CA.

[SvenHammann90]

Thank you for linking to the document, very interesting read. In particular, the part about the offline process. It is certainly possible to also publish "well-known DIDs" offline, but then verifying them would probably not happen very often and reliably.

What I am still struggling a bit to understand is the role of a DID registry (distributed ledger) in this "trust bootstrapping" process. Does a DID registry (as suggested by the "Layer 1" picture) exclusively map DIDs to DID Documents? Or could it, e.g., also contain a list of "well-known DIDs" that belong to governance authorities, outside of a DID document? Such that, if I trust the ledger and its governance, I would be able to trust this list? That would make sense to me, but it does not seem to be described this way.

The following part in the "Trust Anchor Discovery and Verification" suggests that a list of "trust anchor DIDs" could be published in a DID document:

DID Documents. For a relatively small set of trust anchors, the governance authority can publish the list of trust anchor DIDs in a DID document on one or more DID networks of its choice.

However, this still leaves open the question: To obtain this DID document, I would have to know its DID. How do I obtain this DID authentically?

[swcurran]

The DID Registry exclusively maps DIDs to DID Documents. It does not contain a list of "trusted DIDs" and in fact, takes (almost) no opinion on the trust-worthiness of DIDs. The only DIDs that it does trust are those of the Trustees (those that started the ledger - created the genesis block), and those of the Stewards, the nodes that operate the ledger. Those are trusted through a variety of human vetting processes. For example, there was a recorded ceremony (video recording is available) of when the Sovrin ledger was created and all of the participants added their transactions to the ledger. That is the root trust of the ledger.

I didn't find the section name you referenced, but if it mentions publishing trusted DIDs in a DID Document, I need to remove that.

All other trust coming from the system as a whole is through Verifiable Credentials and human processes that are completed and then recognized by the issuance of one or more verifiable credentials. As such, your trust comes from whether you trust the issuers of the (possibly chain of) verifiable credential(s) presented to you. You will trust "root" credentials from the evidence you receive from others about whether you trust them or not. That's the human part of the process mentioned in the article.

This is very similar to the CAs today, where you trust them because the browser-makers have baked in the CAs that are defined as being "trusted" (or in some cases, "useful", since not all CAs are really vetted). In this case, the sources of trust are much more diverse, and you (or someone you trust) are in control of what credentials you accept.

[SvenHammann90]

Thank you again for your detailed reply, this does help clear up my mental models. I realize that some of what you wrote is specific to Sovrin, but I still wonder if some of it could be addressed in a general form in the Trust-over-IP RFC.

For example, the section "Layer One > DIDs > DID Methods" mentions

DID methods can be designed for distributed databases, file systems, or other system that can serve as a cryptographic root of trust.

I believe it could be worth to clarify a bit about what "root of trust" does and does not mean in this context, e.g., as you stated it: "[The DID Registry] takes (almost) no opinion on the trust-worthiness of DIDs".

I didn't find the section name you referenced, but if it mentions publishing trusted DIDs in a DID Document, I need to remove that.

It is in "Layer Four: Governance Frameworks > Trust Anchor Discovery and Verification". I mentioned Layer One previously; sorry about the confusion.

I believe I may also have misunderstood the term "trust anchor". I took this to imply some sort of "root of trust", but it is actually defined to be "authoritative issuer of credentials".

You will trust "root" credentials from the evidence you receive from others about whether you trust them or not. That's the human part of the process mentioned in the article.

I believe I understand this better now on a conceptual level. What I am still a bit unsure about is how this would work in practice, and whether we will end up with "pre-installed trust roots" in agents, for example. But I realize that this might be out of scope of this RFC.

Thanks again for your answers. I am a PhD student and realize that I maybe "academically overanalyze" parts of this. I am trying to formally analyze parts of the SSI ecosystem, and for this, having a rigorous understanding of these concepts is critical for me.

[dhh1128]

@talltree: I think you need to see this discussion.

[swcurran]

Good answers. I'll try to add a bit more context, and I'll look forward to what @talltree has to add.

While the comments were in a Sovrin-specific context, all public permissioned ledgers have the same requirements about who is allowed to write transactions. As long as the ledger is "sufficiently decentralized" (a complex term to define) trust in the writers can be minimized. In permissionless ledgers, the genesis transactions must still be trusted and the consensus process covers the writing without trusting the writers.

When you reference layer 1 trust above re: files, databases, etc. it is just cryptographic trust, not the "human trust" that I was talking about in the discussions above. So you could know that a file pulled from the system was the same one pushed (no tampering), by using the DID from the ledger on which it is published, but not who put the file there until you can get verification of the DID owner. Which is back to a higher level authentication mechanisms.

Ah - I was confused on what document you meant--our document does not reference that use of DIDDocs in that way. I see how that is used in the Governance Frameworks Layer section of the RFC. I'm interested as well in what that means precisely. I'm guessing it is something like when the Trust Anchors are participants in a partnership that is the authority, but I'm not sure.

I think the term "trust anchor" varies by context. In some contexts, it's at the cryptographic layer, and there are no credentials around. On the other end of the scale, an example is that of trust given an issuer through legislation - derived from the authority of a government. And everywhere in between. Which is really what the ToIP stack shows so well.

[domwoe]

The DID Registry exclusively maps DIDs to DID Documents. It does not contain a list of "trusted DIDs" and in fact, takes (almost) no opinion on the trust-worthiness of DIDs.

I'd agree, but thus this not disagree with the following statement?

If the set of authortiative issuers is relatively small, the governance authority can publish the list of authortiative issuer DIDs in a DID document on one or more DID registries of its choice.

Source

[swcurran]

The key(s) in the DIDDoc enable proof of control over the DID. If there are multiple keys in the DIDDoc and an algorithm to manage control (e.g. must have 3 of 5 signatures to change the DIDDoc). So that is what that second comment means.

However, proving control of the DID does not give us any knowledge about who that is. That is a matter of binding that proof with higher level mechanisms - verifiable credentials. That's the first comment.

Does that make sense?

On Thu, Feb 6, 2020 at 2:48 AM Dominic Wörner notifications@github.com wrote:

The DID Registry exclusively maps DIDs to DID Documents. It does not contain a list of "trusted DIDs" and in fact, takes (almost) no opinion on the trust-worthiness of DIDs.

I'd agree, but thus this not disagree with the following statement?

If the set of authortiative issuers is relatively small, the governance authority can publish the list of authortiative issuer DIDs in a DID document on one or more DID registries of its choice.

Source https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0289-toip-stack#discovery-and-verification-of-authoritative-issuers

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hyperledger/aries-rfcs/issues/406?email_source=notifications&email_token=AAHYRQXYGG66YU4GV5ZUIMTRBPTJDA5CNFSM4KN2DL7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK6YLHA#issuecomment-582845852, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHYRQTISYZUYMK7HJ3UN2DRBPTJDANCNFSM4KN2DL7A .

--

Stephen Curran Principal, Cloud Compass Computing, Inc. (C3I) Technical Governance Board Member - Sovrin Foundation (sovrin.org)

*Schedule a Meeting: *https://calendly.com/swcurran https://calendly.com/swcurran

[SvenHammann90]

Thanks @swcurran for answering all my questions.

I have thought about this issue some more and realize that "where the chain starts" with respect to mapping DIDs to "real-world entities" is ultimately specific to each governance framework.

I realize that it is thus probably out of scope to discuss for the TOIP RFC - thus, you can feel free to close this issue. I will leave it open for now, in case, e.g., @talltree wishes to comment, as Daniel suggested and I would of course appreciate.

[dhh1128]

@SvenHammann90 : I just raised a PR for an RFC that touches on your question. It is only a partial overlap, but may be interesting to you. See #431

[kdenhartog]

After PR #431 is there any more action we'd like to take on this issue?

[swcurran]

I think we can close it. I'll do that, and see if anyone disagrees and reopens it (which would be fine).