Interoperability between de/centralized identity providers

Opinions •
Sep 14, 2019 • logged_by: Charles

During Web 3 Summit 2019, the Identity Node hosted an open discussion on interoperability between centralized and decentralized identity providers with Pelle Braendgaard, CTO of uPort, and Charles Cunningham, a core developer at Jolocom.

Interoperability is a key area of focus within the decentralized identity community and the topic has proven effective fodder for meaningful discussion at all levels of abstraction. For a slice of a more recent dialogue within the community, you can read The DID Dilemma submitted by members of the DIF as well as an open statement to the community which we co-authored with Danube Tech.

Below are highlights from the discussion on interoperability we hosted at Web 3 Summit on 21 August 2019, as well as a complete transcript.

Note:
This transcript was recorded by hand in real-time. Please accept any typos or inaccuracy as human error and not a reflection of the speakers.

Non-correlatability

Philosophically, I think that people generally agree with the concept of non-correlatability. Everyone wants privacy.

I see a lot of the same errors arising when our crypto engineers find an algorithm that they think will be a magic fix simply because it’s beautiful. At Sovrin, they have built a beautiful technology, and they’ve built it specifically to not correlate individuals’ identity information but one of the things they forget is that the number one use case for identity is correlatability. The purpose of identity is to be able to correlate yourself as an individual to some other use case. And if you remove that, it removes the core use case of identity.

DIDs & DID methods

A DID is short for decentralized identifier…essentially the DID is the equivalent of a URL in the decentralized identity space…The DID method is a way of looking something up on a blockchain.

Elegant solutions separate problems at the joints.

Centralized providers & interoperability

Should decentralized protocols cooperate with centralized protocols in the sense of Facebook or Libra? There are those who are against interoperating with something like this for ideological reasons. Personally, I think that while we should be wary of protocols like this, purposefully preventing interoperability is sort of against the whole point of DIDs, which enable everyone to talk to everyone.

A lot of the debate is because we propose a simple way for businesses to create a DID. We proposed what is now called the web DID method (did:web:jolocom, for example.) Then you can place a DID document that is protected by DNS. Does it use a blockchain? No, but it works. It allows a business to experiment with creating Verifiable Credentials without figuring out how to create a blockchain based DID.

Blockchains are not necessarily the best solutions for many use cases. We want geographical decentralization with logical centralization.

A distinction should be made between websites hosting their own identities and Facebook becoming a provider of identities…If they did it properly and they didn’t have control over it and they had a sufficient number of validators, it’s possible that Facebook could create a great DID method for SSIs, but I doubt that they would.

Centralized companies could easily take over if excluded at this stage. I also believe it makes sense to find certain rubrics to categorize these DID methods. There’s a paper being submitted at RWOT in Prague where you can categorize certain DID methods by the governance model of certain layers.

Usability

Governance is really tricky and use case specific. Often the issue is not implementing it technically, but coming up with the right socially acceptable solution for these programs. Tech-wise you can implement any kind of DID method that you want. It often comes down to how this will look for the user and what will make sense technically.

Think about crypto. With crypto wallets, the user is required to save their seed phrase. We are making assumptions that everyone knows what they are doing. This is just like what Open ID did in assuming that everyone on the internet has a blog. Now, everyone should know how to manage keys. And if we continue down this path, all of this decentralized technology will be centralized again.

A birth certificate or a passport were the credentials of 200 years ago. We get very focused as the “identerati” on these 200 year old concepts and I question the relevance of them today…The “identerati” need to be less concerned with making a digital passport, but with how can end users take control of millions of data points.

Facebook and Google hide all of the complexity. They don’t show the real power of what they have to the user. The fundamental reason is that it gives users access to things they didn’t have access to. What’s not important for the user is how.

UX is really a challenge for us. What we do doesn’t map easily to existing infrastructures or systems. It’s hard to demonstrate in an easy way to users how to carry out the actions. Ideally users would never know what a DID or a DID method is.

From a legal point of view the regulation around data privacy puts a lot of pressure on UX. There’s a question beyond “what’s the message you send to the user about what’s going on with the software,” but also how you structure the message in a friendly way.

UX and the legal aspects are two of the most important things. There’s GDPR, sure, but there are other issues. TORT will be a word that people in the crypto world will get used to. Like if you have ice in your driveway and someone slips on it, it’s still your fault. If you are telling someone to link to your ethereum address and it has info inside of it, then it’s your fault.

Interoperability

Mutual resolution is the first step which we must do between uPort and Jolocom, but now we’re working on it. The idea is that within a year or so the final parts for this really simple use case of me logging in should be solved, making interoperability possible between two providers.

We have the authentication working group which deals with authentication based on DIDs. I’m chairing it. We have a proposal for DID authentication which is based on Open ID Connect profiles. The intention is for it to become compatible with Open ID Connect, but to add privacy security guarantees we get from DIDs. I’m not sure if you’re aware of the interoperability project in the DIF. By the next IIW, the first goal is to be able to sign into a web application with DID authentication. We have a proposal, and the intention is that all the DID wallet providers, including Sovrin and Evernym or these peer DID people, should potentially be able to implement it. There is ongoing effort and I am optimistic.

Standards Groups

IIW and RWOT are the two primary watering grounds for the “identerati.”

[DIF, W3C, Hyperledger Aires, INATBA, and other identity and blockchain working groups] have the same goal, but still different sub-goals. DIF and W3C guidelines and specifications diverge slightly. DID Comm is not supported by W3C, which doesn’t have a position on DID Comm. INATBA doesn’t have that many recommendations yet. I think there’s a lot of room for consolidation. Even at IIW and RWOT there are 100 projects that don’t even describe themselves as SSI. Provisioning machine identity is a whole other niche world.

Of all standards bodies around the world, I like IETF, the whole culture around it is what the internet was built on.

Full Transcript

Charles:
What’s your opinion on Sovrin and their approach to non-correlatability? Philosophically, I think that people generally agree with the concept of non-correlatability. Everyone wants privacy.

Pelle:
Sovrin very much takes an engineers’ approach to the problem. I see a lot of the same errors arising when our crypto engineers find an algorithm that they think will be a magic fix simply because it’s beautiful. At Sovrin, they have built a beautiful technology, and they’ve built it specifically to not correlate individuals’ identity information but one of the things they forget is that the number one use case for identity is correlatability. The purpose of identity is to be able to correlate yourself as an individual to some other use case. And if you remove that, it removes the core use case of identity. And while there is a beautiful system that has been created, it makes it hard for users to take control of their information. We need to find the right middle ground that enables users to take control of their information.

The other major challenge is that they can’t interoperate with anything.

Charles:
I can’t wait for Hyperledger Indy to spin out into Rust to create the privacy dream, but the unfortunate reality is that for other services to function, it could only work in a certain way. Correlatability has trade offs.

Do they use DIDs or verifiable credentials?

Pelle:
Things change a lot with what they do and like many amazing technologists, they aren’t the best at documentation. My understanding is that they have a DID method.

A DID is short for decentralized identifier. It is a new W3C standard, meaning that there’s a bunch of legal things that are associated with it. But essentially the DID is the equivalent of a URL in the decentralized identity space and the really clever thing about DIDs is that they create a way of abstracting when talking about identity. How do we verify things are signed by a particular identity. The basic use case is that if you have a DID you can figure out the DID method.

The DID method is a way of looking something up on a blockchain. You can find a document and sign for it. You can exchange the X500 system to verify some piece of signed data.

Charles:
On the did:jolo method — DID documents are defined in the spec as JSON or JSON lD documents. When you create an identity, you have a smart contract that makes a mapping between the DID and your IPFS address.

The good thing about having methods is that you can define how this works. You can have a centralized service and still use a DID and there are people arguing fiercely about whether or not that’s a decentralized identity. But anything basically that is a DID, and speaking about interoperability, the universal resolver can take kids from multiple DID methods and functions as a super DID method.

Verifiable credentials are are using DID methods distributed public key infrastructure functionality. They make statements about each other or themselves and this is basically the abstractions that most SSI companies make about credentials. A driver’s license can be issued to you from the state or someone else and there’s really any number of abstractions you can make, conditions under which they are valid or not valid, whether they’ve been revoked, and more. They’re really neat. They enable base level understandability between DID methods.

The current limit is between communication formats to request information between methods. We have a defined set of interaction tokens and they aren’t standard. But DIF is currently working on a similar thing between communication methods.

Pelle:
DID Comm is an interesting new standard that is trying to figure out how we can all communicate. We’ve been doing this for four years and have been recommended three different ways of doing things. Did Comm is one of the great things that the Sovrin guys came up with. We are having some debates on philosophical differences, but it’s an area where we can get interoperability. Everyone has agreed it’s a good idea and we are at the level of nitty gritty dotting Ts and Is.

The way it works is that DID Comm allows you to create an encrypted message and send it to one or more other DIDs. You do this by looking up in your DID document a service end point and then you encrypt a message and send it. And it’s one of these good standards because it solves a really clear problem we all have in a generalized way and it doesn’t do anything else.

There is a tendency in many areas to try to do way too much becaufore we know what the use cases are.

Participant:
Is there standardization around how you send messages?

Pelle:
DID Comm is designed to be agnostic…We forget about the beauty of simple layered protocols so you can layer on top of these other things that we already have.

Charles:
There was an interesting quote — elegant solutions separate problems at the joints. Having these layers is a good way to separate problems at the joints.

Another question for you — should decentralized protocols cooperate with centralized protocols in the sense of Facebook or Libra? The libra white paper indicates that an identity layer will be needed to function and will include real life names and details.

There are those who are against interoperating with something like this for ideological reasons. Personally, I think that while we should be wary of protocols like this, purposefully preventing interoperability is sort of against the whole point of DIDs, which enable everyone to talk to everyone.

Pelle:
I agree with that. If you talk about our good friends at Sovrin, they have about 60 validators. This is pretty decentralized, but not compared with say Ethereum or Bitcoin.

Now compare that to something like Facebook or google, which has central ownership, but on the technical side may be way more decentralized than even Sovrin.

We need to be pragmatic and not get into these often ridiculous arguments.

A DID serves a particular purpose. A lot of the debate is because we propose a simple way for businesses to create a DID. We proposed what is now called the web DID method did:web:jolocom, for example. Then you can place a DID document that is protected by DNS. Does it use a blockchain? No, but it works. It allows a business to experiment with creating Verifiable Credentials without figuring out how to create a blockchain based DID.

Charles:
Blockchains are not necessarily the best solutions for many use cases. We want geographical decentralization. We want logical centralization which is cooperating around protocols and formats and the layers of your protocol stack.

Ellie Stephens (Jolocom):
Are there downsides to allowing centralized providers? And how would it work from a marketing perspective? How would users be able to tell the difference between centralized DIDs and decentralized ones?

Pelle:
A distinction should be made between websites hosting their own identities and Facebook becoming a provider of identities. They haven’t done it yet, so I can’t comment on how it would work. If they did it properly and they didn’t have control over it and they had a sufficient number of validators, it’s possible that Facebook could create a great DID method for SSIs, but I doubt that they would.

Oliver Terbu (uPort):
Centralized companies could easily take over if excluded at this stage. I also believe it makes sense to find certain rubrics to categorize these DID methods. There’s a paper being submitted at RWOT in Prague where you can categorize certain DID methods by the governance model of certain layers. As a community we should come up with certain use cases which require certain DID methods. Even the peer DID method — is it really centralized? It’s between two parties and if one party decides not to be your peer anymore it’s gone.

Charles:
Governance is really tricky and use case specific. Often the issue is not implementing it technically, but coming up with the right socially acceptable solution for these programs. Tech-wise you can implement any kind of DID method that you want. It often comes down to how this will look for the user and what will make sense technically.

Pelle:
DID methods don’t mean anything on their own. What means something is the verifiable credentials. It only becomes really important once you as the person prove you are the DID method.

Participant:
Sovrin uses a different DID for interactions and it’s this which stays at the basis. I see a two-way relationship between a user and a possible entity. So when you talk about correlations do you talk from the entity perspective or the user perspective? It’s good for me to correlate my interactions as a user, but not for an entity to be able to correlate interactions about me.

Pelle:
The Sovrin approach is what you are saying. They use a peer DID method and…which makes it very hard to interoperate with. It’s not meant to identify with any individual, its meant to identify both entities in a communication. The other party cannot take this message that you have. It’s non-reputable. Lawyers have always said that the idea of non-reputability doesn’t exist because in actual contract law, you can always repudiate something. When we do something with Google or Facebook we can obviously correlate these actions…

Another important part of these verifiable credentials are a very specific form of signed data. We like to talk about verifiable data. The “identerati” always talk about credentials and you continue hearing the same use cases from the mid-2000s. My eyes start rolling when I hear 0 knowledge use cases myself and I know I should just shut up.

When we look at real world digital identity today, we think Facebook and Google. The important part we need to ask ourselves is do they have a digital driver’s license? No, because it’s not important for their use case. If we’re trying to make sure end users can take control of their data, we need to emulate some aspects of what they’re doing. The “identerati” need to be less concerned with making a digital passport, but with how can end users take control of millions of data points. A situation where users can go in and decide to take control of certain aspects of theirown identities.

We don’t want to be able to go into Etherscan and correlate anything, which is what a lot of identity projects are basically doing. There are GDPR issues there. And people are controllers even though they don’t hold the keys. If you’re telling people to do really really stupid shit you are the controller and can still be liable.

We need to work on user-controlled correlation. We need to have the idea of peer DIDs where we have pairwise identifiers and you have a new DID identity for each person or business, then they can’t correlate things elsewhere and you can start getting these benefits.

We should never forget that this (did:abs:123) is not a person. Who has the best algorithm? This isn’t the way we should approach this problem.

Participant:
A digital name is just another piece of info, a string.

Pelle:
I write a talk about the origins of identity. The village is the original Etherscan. Everything is correlated to you in this particular area. But it wasn’t particularly scalable, so we needed to introduce these magic things called credentials to allow us to move from the city. A birth certificate or a passport were the credentials of 200 years ago. We get very focused as the “identerati” on these 200 year old concepts and I question the relevance of them today. So we ended up in this world where these credentials came and we started having central registries. In some respects I like the concept of the village, but if we can recreate just some of these ideas of the village and decide how to correlate them and in which village you’re in, this is the perfect way.

Charles:
I think that because these 200 year old ideas are so entrenched, they function as a way to enable or prevent people from doing things. But it’s going to be very difficult to escape them because every use case people jump to is credentials. I love the idea of zero knowledge proofs for identity, but we’re using brand new tech to emulate these older concepts. I can’t imagine what we’d do alternatively. Should we organize societies this way? I think there’s a balancing act between enabling interoperability. If the specifications are too tight then nothing changes.

Pelle:
All of us “identerati” have this vision in our head. We have different world views, we have different use cases, and these things like encoding formats and other small details end up in the working groups.

To interoperate we must pick the battles. Say “this fits with everyone’s world view, so we do this.” We must get to the point where we all continue to try to experiment. There’s no product-solution fit — we are making this shit up. And if we are creating massive standards based on this no one will use it.

Think of X500 in the 80s. It was supposed to be huge and they implemented all of these convoluted standards globally and it failed and it was replaced by a very simple protocol — combined SMTP and DNS. It worked because we didn’t need to know the physical location of someone to send them an email. And the X500 people couldn’t compute. They spent millions on this kind of process that was a failure.

In the DID space, one of the earliest examples of this was Open ID which was a decentralized identity protocol, not designed as a federated identity protocol like it is today. It was supposed to be for everyone to control their own identity. So we could finally get rid of Microsoft, the big enemy tech giant back then. To do this, you had to have a blog on your own domain name, and then install software. It was decentralized but it made a lot of assumptions. Who has a blog? Then it tried to have a button. In the tech space we call this the NASCAR problem. Because then there were 40”:login with” buttons. Then came Facebook connect. It was simple, one button and people went towards this. The Open ID people made all these very obvious assumptions, but usability wasn’t taken into account.

Charles:
If someone only has their ID on their phone and isn’t connected to the internet, and someone wants to send their DID, is it necessary to have asynchronous communication?

Pelle:
You don’t have to respond to it immediately. There has to be a place for users to respond to messages. The DID Comm spec solves the security aspects of it.

Participant:
What are the interoperability points? Is it encoding? It’s not like there’s only one thing that has to be done.

Charles:
I would define it as mutual interpretability or intelligibility. That’s equally as vague. In the same way you have a stack of different protocols. Two people using TCP can send different packets to each other. People can send messages to each other using DIDs.

Pelle:
The only areas where it makes sense to interoperate are the only areas where we have the same needs and requirements. Sovrin’s DID method is specifically designed that the only people that can resolve it are the people involved in it. As we get closer and closer to product market fit and solution fit, we need to think — why would people really want to use this?

Participant:
If someone was going to start to try to use this for real, do they have to say I only work with the uPort or Jolocom wallet, or do I have to do an interface between the two?

Pelle:
At uPort we differentiate between on and off chain interactions. If we all install each others DID resolvers…mutual resolution is the first step which we must do between uPort and Jolocom, but now we’re working on it. The idea is that within a year or so the final parts for this really simple use case of me logging in should be solved, making interoperability possible between two providers.

In this particular space, there’s another use case that we see as being quite important. We want to utilize it on the chain in a way that’s not correlatable. A lot of the work we’re doing with DIF and the W3C has started using JSON LD…they don’t really translate to working on chain. uPort was designed from day one to do off chain correlation of something, and prove you own a particular ethereum address. But this is now a very important use case and very important for blockchain to solve.

Not on the DIFs radar. EIP1056 and 1812 are what underlie our DID method. It’s key to understand the correlation inherent in on-chain interactions. Blockchain for identity but off chain use cases. One of the key areas where we might get some product fit is identity for blockchain. Microsoft and IBM are very focused on using blockchain for identity. Not vice versa. Blockchains already have their own identity model on them. We believe that model can also be used on other blockchains.

Participant:
I’m assuming that authentication is an integral component of your identity. Is there any W3C work on authentication?

Oliver Terbu (uPort):
We have the authentication working group which deals with authentication based on DIDs. I’m chairing it. We have a proposal for DID authentication which is based on Open ID Connect profiles. The intention is for it to become compatible with Open ID Connect, but to add privacy security guarantees we get from DIDs. I’m not sure if you’re aware of the interoperability project in the DIF. By the next IIW, the first goal is to be able to sign into a web application with DID authentication. We have a proposal, and the intention is that all the DID wallet providers, including Sovrin and Evernym or these peer DID people, should potentially be able to implement it. There is ongoing effort and I am optimistic.

Charles:
We have a beta version of our wallet that can resolve to the universal resolver. But then the next step is verifying…encryption schemes. Stuff can get hairy quickly and we have to go down every single path if we want to interoperate with everyone.

Pelle:
There is this universal resolver and I find it quite ironic that the universal resolver to resolve DID documents is itself a centralized server. The idea is that you resolve things on your mobile phone. We run a javascript typescript. We’ve done a lot of work on the infrastructure. And we’re pushing all of our DID resolvers into DIF. And we’re trying to figure out how to abstract away things like signing. Looking at a lot of the work the…people are doing with javascript. Mark Millers’ work over the last 20 years…they have a way you can securely load in javascript. This is really interesting on some of these things. This is where interop is great. How do we handle these types of things and make them usable?

For the resolver to work we have to install one hundred different DID methods. Just to get the ed3904290 and sep256k1 into the browser is 250k and I analyzed the dependencies — there’s a 500mb dependency to be able to do DID Comm. We need a safe way to be able to load these things securely and add DID methods and signing methods and experimentation. This is one of the areas where we can do a lot for interoperability.

IIW and RWOT are the two primary watering grounds for the “identerati.”

Charles:
No one will ever run a full node on their phone. There’s already a gateway issue for all blockchain projects that want to read information and not run a node. And we should get together around DID Comm and interaction token formats and DID spec when it changes and issues arise and put together an easy way to deploy new DID methods.

Oliver:
How do you see the relationship between DIF, W3C, Hyperledger Aires, INATBA, and other identity and blockchain working groups?

Charles:
All of these working groups have the same goal, but still different sub-goals. DIF and W3C guidelines and specifications diverge slightly. DID Comm is not supported by W3C, which doesn’t have a position on DID Comm. INATBA doesn’t have that many recommendations yet. I think there’s a lot of room for consolidation. Even at IIW and RWOT there are 100 projects that don’t even describe themselves as SSI. Provisioning machine identity is a whole other niche world.

Pelle:
Most of these different standards organizations were created to do different things. Linked Data never quite achieved any solution fit but they are very focused on it in W3C(??) And like many standards groups they feel like they need to own this. I heard we should be doing that in the DID comm. Of all standards bodies around the world, I like IETF, the whole culture around it is what the internet was built on.

There’s a lot of really good interest from countries like Spain where they are creating a nationwide permissioned public network on ethereum and they have an identity layer basically based on our 2017 uPort architecture. They want to have their own DID method. We’ve convinced them there’s no need for this. We need to figure out how to include specific requirements in specific DID methods. “I need a place in this world” is the issue of organizations. DIF has been accused many times of being a fake Microsoft organization. We’re all open. But there’s still lots of politics.

In the current world it’s all about owning user data. This is an issue we have at uPort because we don’t have any data. We don’t have the benefits of traditional platforms.

Charles:
We’ve also been contacted about setting up public permissioned networks for niche concepts. To me, it seems strange to apply SSI to permissioned blockchains.

For everyday people it’s going to be off chain things that are most used, so it won’t matter who hosts your DID document. The sort of fight for having a DID method is not really necessary, but having competing capabilities for DID methods is important. You get cool new stuff this way. The ownership stuff is totally out the window because we don’t have it.

Participant:
How do you correlate the result of uPort to what is a daily identity for someone?

Pelle:
We generate lots of data and this is all part of our identity. Our identity is not like a digital version of a passport. We all know in real life how to do “identity.” We have our work identity — one that’s very serious. Our non crypto identities — maybe those of us who spend the day in jeans and tee shirts in crypto go home and put on a suit at night. Maybe in the village that wasn’t needed. But today, we want our uPort users to be able to do this.

We don’t want to own users’ data, but we want the users to be able to get the benefit of what Facebook and Google are doing. If we can take control of this and figure out how to share it in the right contexts — which profile, which version of me I want to share — I think this is going to be really, really valuable. It’s not just an engineering issue. There are a ton of UX issues. We spend all of our time trying to figure out how to do this in the simplest use cases.

Ellie:
How will our UX compete in developing contexts against something like Facebook?

Pelle:
A lot of this lower level innovation will happen in Africa. There are a lot of people there working on a lot of interesting structures — their own electronic financial systems, for example. Local financial models exist there for people to invest in and save.

Charles:
UX is really a challenge for us. What we do doesn’t map easily to existing infrastructures or systems. It’s hard to demonstrate in an easy way to users how to carry out the actions. Ideally users would never know what a DID or a DID method is.

Participant:
From a legal point of view the regulation around data privacy puts a lot of pressure on UX. There’s a question beyond “what’s the message you send to the user about what’s going on with the software,” but also how you structure the message in a friendly way.

Pelle:
UX and the legal aspects are two of the most important things. There’s GDPR, sure, but there are other issues. TORT will be a word that people in the crypto world will get used to. Like if you have ice in your driveway and someone slips on it, it’s still your fault. If you are telling someone to link to your ethereum address and it has info inside of it, then it’s your fault.