Sharing public keys/DIDs - how does the ledger help?


#1

Referring to the white paper: “How Sovrin works”:
Jane wants to interact with her bank, hence both actors need to know the public key (or a DID) of the counterpart.
The obvious way is to exchange the keys in a f2f session, which is in fact a mutual-identity-proofing event
(in fact, many legislations require a f2f KIC procedure for banks, but let’s ignore this specific requirement).

Are there other ways for Jane to (more or less) securely associate the bank to its public key (and vice-versa)?

My understanding is that the ledger has a role in this via a Web Of Trust process, but I could not find out details on how this happens. The paper mentions: “[…]There are so many lines for the diagram o show all the various interactions with the ledger itself…” which evokes a specific role of the ledger.

Can someone help?
Thank you
luca boldrin


#2

Hi Luca,

There are some quite interesting models out there which could be applicable. What needs to be achieved is the transmission between the identity owner and the relying party of one party’s DID. This allows the other party to look up the DID on Sovrin, find the endpoint in the DDO, and they can establish communications securely peer to peer.

A very nice model I’ve seen from QIY Foundation and their Dappre app which uses simple QR codes. The bank shows a QR code on their website. The user reads it with their app, which then executes the lookup and establishes a link to the bank’s endpoint (note Qiy isn’t using Sovrin at this point, this is just an example - with Sovrin the QR code would contain the bank’s DID).

Person-to-person exchange of DIDs could work in the same way quite simply.

In this way, the DID lookup gives you access to the DDO which contains the public key of the DID owner and their endpoint so you can a) find them and b) interact securely with them. The result is distributed PKI with no need for a central authority, which is really very cool.

An interesting approach is an alias service to give human-readable “handles” which are linked to DIDs using a lookup service. This could have correlation impacts if people aren’t careful (e.g. I could assign the same “Tobers” handle to all my DIDs which would make things awkward).


#3

Thanks Andy for your reply.
My feeling is that getting to the “endpoint” is not enough: many use cases require an association between the endpoint and a real-world entity. This is true for Jane accessing to bank services, buying an airline ticket, renting a car, requiring a school transcript, subscribing for a phone line, accessing to on-line public services…
Anonymous identities are useless in these contexts (in fact, this seems connected to the “privacy vs. accountability” thread).

To my knowledge the traditional way of establishing the endpont-realworld association is via a trust anchor (e.g., a registration authority) issuing a trustworthy claim which associates jane’s endpoint to her real identity. Traditionally, ths claim would only be released after a f2f identity proofing session with Jane. Jane would then need to present such a claim to the bank for opening an account.
Still, it is conceivable that some services are content with less than a trusted claim, e.g., it might suffice to know that such a claim exists and is available on need.

My question is then expanded as: is the ledger merely a tool for endpoint lookup? (I could do that with DNSSEC…)
Or can it provide some valuable information like: “this DID is supported by one/more trusted claim”?
Or even more, can the ledger itself act as a notary holding back the trusted claim until some condition happens?


#4

Correct Luca - you need to be sure you’re talking to a “legitimate” entity. I hadn’t included this in my DID lookup explanation.

So for example the relying party that you look up the DID for could show you a claim confirming that they are part of a trust framework, which is signed by the authority of that trust framework.

In a situation where Jane wants to obtain a claim from her bank, she would already be known to the bank and could be signed in to her online banking app. So when the bank issues the claim to her, they are forming the linkage between her meatspace existence and her digital existence. In this situation the bank would be her trust anchor. It is then up to the relying party to determine if they want to trust a claim which her bank then issues to her.

There is a good market here for “identity proofers” (previously called “identity providers”) to be those initial trust anchors.


#5

Luca, I wanted to add to Andy’s answer on this thread because the question you asked is actually central to the Sovrin Trust Framework (and I chair the Sovrin Trust Framework Working Group).

Andy’s answer is spot on—that the association between a real-world identity and any one of its Sovrin identities (i.e., DID and DDO) is not proven by the Sovrin ledger itself, but by verifiable claims that are issued and digitally signed by other DIDs stored on the ledger. This means it’s not the Sovrin ledger that serves as the root of trust, but each individual DID on the Sovrin ledger serves as its own root of trust.

This is a fundamentally different trust model than hierarchical CAs (certificate authorities). It’s a web of trust model. The web of trust is not a new idea—as the Wikipedia page explains, it’s over 25 years old. What’s new is using a decentralized ledger for all of the trust roots.

For example, there can be billions of DIDs on Sovrin and you may not trust 99.9999% of them. But of the 10 DIDs you do trust (perhaps because you personally know the people or companies that own them), you know their Sovrin identity records are very strong because those DIDs and DDOs are written to an immutable distributed ledger that is nearly impossible to tamper with.

And starting from those 10, you can use verifiable claims to determine who else you might trust. So you can organically grow your own web of trust built on the trust roots YOU select. And I can organically grow my own web of trust based on the trust roots I select. And so on.

As we build these digital webs-of-trust, more and more of them will intersect, and we will be able to form new trust relationships more easily, which can have all kinds of beneficial effects for commerce, society, governments, etc.

I call this the web of trust network model because even though no two Sovrin identity owners may share the same DID trust roots, we all share the same global identity network—Sovrin. Which means we all have the potential to develop intersecting webs of trust as soon as we have at least one common DID trust root.

Make sense?


#6

So if I’m right then, in the case of Alice and Faber, there should be some up-front verification between Alice & her agent and also Faber and their agent to establish some sort of identity verification.

What are you thinking of for that?

E.g., how does Alice establish that she is the specific Alice that Faber knows?


#7

If I correctly understand your question, Andy, you wonder how Alice can ascertain that a certain DID corresponds to a precise person.
As far as I know, in traditional PKI there are some “trust anchors” that we definitely need to take for granted. They are normally root certificates embedded in browsers (the certificate repository), in client applications (e.g., Acrobat trust list) or offilically published somewhere (e.g., the European Trust List). All other associations are derived via chain of trust from these inital anchors.
In WOT approach, as Drummon mentions -yes, it makes sense!-, this might happen because I personally know some people and they communicated their DID with me off-ledger - they would become tust anchor just for me, not for the rest of the world.
Sovrin paper also mentions a role for government institutions, whose DID I could easily recognize if they make it publicly available, e.g. on their institutional web site.


#8

Hi Andy - I’ve just seen this question.

Faber will need to check who Alice is. There’s no getting around this. See the thread on “meatspace to bitspace”. The most likely scenario is that Faber will see Alice in the flesh when she enrols, and check some ID information (maybe digitally, maybe physical hard copies), and then establish the Faber/Alice pairwise relationship. At that point Faber can write a claim for Alice confirming her as a student of the college, and Alice can use that claim from then on within Faber and outside.

It would be the same in your passenger passport example. The airline will need to confirm who the passenger is in order to issue a claim to them.