DID is the Edge - Each Identity Owner is their own many-faced god


In the TF working group, we have been trying to figure out what an Identity Owner is, and what they need to agree to in order to sign the IdO Agreement. We’ve agreed enough to get started on the Provisional Network, but some key questions remain on this bridge between the SN and the real world. All DID’s need to be related to the a real person or organisation (group of people) but how do we know that whilst maintaining anonymity and the self-sovereign ID? Do we need to be able to prove that? One of the elements we intend to include in the IdO Agreement is

" Use a Sovrin Identity to impersonate another Identity Owner or otherwise misrepresent the Identity Owner’s identity or relationships."

Scott’s brilliant insight: This is about edges vs nodes:. Sovrin Identity is off-network, the SN is like a telecoms network, we need minimum criteria for a DID (like a 'phone number) and then focus on enabling connections (edges) rather than what they’re going to be used for or who’s making them (node). Building network and its traffic is all about the edges vs the nodes. There are plenty of examples in the world of telecoms to prove this point (https://en.wikipedia.org/wiki/Rabbit_(telecommunications))

This means that instead of thinking about a DID as representing an aspect or persona of a person, organisation or thing (the node), we think about each DID as representing a relationship (edge between an . A and B party, we hope that most connections will be A:A, an act of recognition of a persona. But often they will be A:B_n_

This is the difference between setting up a profile for your best mate on facebook, and posting a photo of your best mate on your own facebook profile. Even if it’s a bad actor trying to set up a DID impersonating you on the SN, that is still a valid relationship (ie you are his target).

The node-centric view of this is that each ‘Sovrin Identity’ (or possibly Identity Owner) is effectively their own many-faced god (http://gameofthrones.wikia.com/wiki/Many-Faced_God) going by different names (bits of PII) in different pantheons and faith structures (Trust Frameworks/ Contexts) but amounting to the same Sovrin Identity.


Change IO obligation to:
" Use a Sovrin Identity to misrepresent a relationship you have with a natural person, legal organisation or thing, at the time when the DID is created or used to transact, that natural person might in most cases be you"
"Use a Sovrin Identity to lay claim to be another person, organisation or thing, at the time when the DID is created or used to transact"

There are lots of ways you could prove both without needing to know who the IO is who’s creating the DID

Could be some thoughts for the GA TF


@NickyH, I just love the insight that DIDs on Sovrin represent an “edge” (relationship) rather than a node. And I love the “many-faced god” analogy even thought I haven’t been able to watch Game of Thrones yet (too much time spent developing protocols and trust frameworks :wink:

I think I get implications, i.e., your proposed revisions to the Identity Owner obligations in the Identity Owner Agreement. But I’d want to talk them through with you a little before I try to capture the new language.

Since we’re going to be revising that language anyway, I’m thinking I’ll post the proposed update here on the Forum after the special Trust Framework Working Group meeting we have on this topic tomorrow (Thursday) morning and then we can collectively polish it.


Nicky, I am a bit lost, could you please clarify the meaning of “DID as a edge A:B” ?
A is the IO, while B is the TA issuing the DID?
A is the IO, while B is the party this DID is intended for (as a pairwise identifier)?
In both case, I cannot figure out what A:A and A:B_n_ stand for.
Thank you!


Hi Luca

A Party & B Party, let’s call them Alice & Bob

If Alice sets up a DID for Bob as an edge it means ‘alice has a relationship of some sort with Bob’ vs as a node: Alice is pretending to be Bob

A:A Alice sets up a DID for herself as an edge, this is a relationship i have with myself in this context as a node: Alice is setting up a persona for herself

A:B_n_ Alice sets up a bunch of DIDs for Bob, Barbara, Bertie etc all friends coming to her 4th July Party, the DID as an edge represents that relationship between Alice and her B Party friends, she might set up other DIDs for these friends related to other activities they share. node: Alice is in fact trying to impersonate her friends and maybe a bad actor

A:B_n_ Alice Springs Tours Pty sets up a bunch of DIDs for their customers, they describe the relationship that the company Alice Springs Tours Pty has with those customers and can verify that their customers have indeed visited Uluru, and the art they purchased was genuine Aborigine art rather than a fake from Indonesia.

… does that make sense?


Much clearer, thank you Nicky.
However, I miss the value of tagging relationships with a DID.
Identifiers are used to aggregate data, attributes, claims. Which data would be worth associating to the relationship?
My feeling is that what you are presenting is not a DID for the relationship, but a DID for representing Bob from Alice perspective (Alice’s view of Bob, hence a “fake” Bob). This “fake” Bob DID would be a muppet under Alice’s control…
Obviously, AliceSpringTourPty could attach a claim “has visited Uluru” to his fake customer Bob, but Bob would not be able to use that claim himself, since the DID would not be under his control.
Just trying to understand, so I apologize if I got it wrong…


Hi Luca, I think we agree - Bob from Alice’s perspective = their relationship. I just thought it might help us think about the TF in a different way, like a telecoms network. If the act of creating a DID is like placing a 'phone call, and Bob doesn’t answer, it is indeed a fake Bob, and no claims can be attached but if Bob does answer, then the connection is completed, the relationship and associated claims are verified.

This reflects one view of identity which I hold pretty dear: There is no such thing as absolute identity, identity is a function of context (social, temporal & spatial). Identity after all comes from the latin _idem_the same. So what defines our identities (or at least the attributes & claims that make them up) is the sameness with those around us not what makes us unique.

And no need for concerns about ‘getting things wrong’ I am often guilty of obscure peregrinations which help no-one but me - this is probably one of them! Thank you for indulging me ;0)


This is an interesting discussion going on here.

I’d like to comment, however, that when considering the epistemology behind “identity” (latin idem), I don’t think it exactly refers to the “sameness” with those around us (although it’s indeed valid to talk about “national identity” and similar constructs), but more precisely it refers to the relationship towards everything that is “the same”, that is exactly one-self, or the set of “things” that are able to define what (or more precisely which) this self is. It is a reflective relationship, or a set of relationships with one(or about one)self. Thus it makes perfect sense to create a DID as a relationship with oneself for setting up a “persona” within the context of the Sovrin network.

However, there’s another perspective that I’d like to share about identity or this quality of sameness, and it’s about identity as the set of “things” (or features, or facts, or claims) that allow two different entities to be able to refer to a third one and somehow be sure they’re talking about the same (idem) person. That’s why we have names, because names act as “identifiers”.

I think the latter aspect is mostly what identity is about in the context of society and laws. Governments issue ID cards, for example, to assign a number through which each person can be properly identified, which is to say that any number of entities referring to a single identifier can be sure to know they’re referring to the same individual,

This last point is something that, at least personally, clashes once in a while with the concept of “full anonymity” or the creation of a DID per relationship… I understand these are features that make a lot of sense for guaranteeing self-sovereignty, however, I’m also trying to see things from a KYC perspective: does it really make sense to be completely anonymous or have a different “face” per individual relationship when my goal as a person (in this context) might be to be able to prove the consistency of “identity data” among multiple institutions?..

My current guess is that although creating a DID per relationship is a powerful and necessary feature, also “relationships” not only occur between entities, but also between entities and contexts. Therefore I could be using the same face within the financial context (even towards multiple different banks), and another “persona” within other contexts, saving for myself the correlational possibility.

It seems to me that correlation might be a desired feature in some contexts… What are the views of the Sovrin community with regard to this?


Hi Carlos,
I think you are spot on, and thanks for the insight on what idem means as a set of attributes that relate to s a single unique individual. However, as you say this [quote=“cbruguera, post:7, topic:187”]
clashes once in a while with the concept of “full anonymity”

I’m not sure you can ever have this, I have just been beginning the gargantuan task of considering the implications of GDPR on my business. The essence of this as explained to me by one individual is 'if there’s anything that could in anyway enable a 3rd party to identify an individual, then you have to be able to delete / forget it". This is really tricky and something wrestled with over many ID & data product development projects. Basically you can figure out who someone is very, very easily. You don’t need any identifiers, and even if there are lots of safeguards on individual attributes, it’s pretty easy to figure out who a person is if you ask 3 or more questions. (see https://www.amazon.co.uk/d/Home-Kitchen/Hasbro-Guess-Who-Game/B00ZWPRH3G)

So to that extent you are right, we can’t offer full anonymity. In a way this is what brings the two meanings of idem together. The things we hold in common with those different social groups (nation, workplace, home town) are enough to create a venn diagram with a small number of, or single identifier, at its heart. Every time I have worked on protecting privacy in this context we have ended up with the same list of things that we have to do (technical, commercial and contractual) to ‘make you forget’. I think this is doubly difficult on a ledger that is there for all time. When I worry on this in the wee hours, I always ask myself the question - “do they want to be anonymous?” My answer is normally: “No - they want to be recognised and valued, they just want to control by whom and in what context.”

With respect to your KYC question and the relationship between entities & contexts - this is very interesting. I wonder what you mean by ‘context’. Could you be happy if you define a persona say ‘financial persona - e.g. my bank ID’ or ‘career persona - e.g. my linkedin profile’ then define relying parties in certain categories e.g. Financial Services Companies, or Potential Employers?? This suggests that rather than a permissioning system that relates to the data that organisations have about us (typically opt-in/out), we should have permissioning systems that relate to the data that individuals have about themselves and then share / don’t share with sets of RP’s. It won’t surprise you to learn that I have some pretty strong views on this. Current permissioning systems are 1 dimensional and completely ignore context, they relate neither to the person nor to the transactional context and are therefore pretty useless. They treat data as a static private or social item rather than recognising the dynamic and contextual value of the permission and the data it relates to.

I absolutely agree with the idea of controlled correlation. Although this would at first appear to be an anathema to privacy, I believe it is one of the key drivers for any individual to engage with and use their digital identity. They want SP’s to make the correlation because this a) says something about our relationship - you know something about me and can therefore tailor your offer to me/ treat me 'specially; or b) saves me a bunch of time, e.g. with form filling. I think the key here is probably ‘permissioned correlation’ . Again this comes back to relationships: Bob & Barbara give permission to Alice to reveal their common relationships (they’re going to the same party, maybe they could share a taxi?) But crucially, neither Bob nor Barbara want Alice to reveal any other relationships or attributes they have in common, nor those other relationships they have with Alice.

Coming back to your many-faced god, you want to be able to choose the face you present in each given context.


@cbruguera and @NickyH: I cannot tell you how happy it makes me to see these discussions here on the Sovrin Forum because it means we have a community experienced enough to appreciate how complex, subtle and sophisticated these topics become.

A few thoughts in answer to your last two messages:

My answer is: absolutely. In fact, I think Nicky nailed the answer:

Here’s another way to put it: in the design of a digital identity system, correlation is both the biggest risk and the biggest benefit.

It’s the biggest risk if the system enables unpermissioned correlation because that can erode trust. It’s the biggest benefit if the system enables permissioned correlation because that’s how you build trust.

With Sovrin architecture we’re trying to do both: maximize the protections against unpermissioned correlation while also maximize the benefits of permissioned correlation.

I’m confident we can achieve both, and in doing so create an extremely useful global public utility for decentralized identity.


@Drummond and @NickyH thanks a lot for your input. It’s good to know we’re more or less on the same page.

We definitely need to focus on developing mechanisms to provide the proper degree of control for identity owners over their data, while providing enough flexibility for covering the vast potential of use cases around Digital Identity.

Looking forward to it!