Oliver Terbu: Beyond the Status Quo: Secure Trusted P2P Messaging

Thanks a lot. Yeah.

So I'm, I'm with consensus mesh. I'm also in the recent foundation, co-chairing working groups on did com and the authentication I was previously on Newport project, but now it's consensus me identity. Yeah. Good. So give a brief intro to my talk today. I wanna talk about problems of current P2P messaging approaches and what could be an alternative based on DDS, how it can be used in an enterprise environment to address certain challenges. So for this, I will specifically speak about DICOM and baseline and how they can work together.

So baseline is another privacy innovation, which I will come back to later on. So what's the problem with current peer to P messaging technologies? I think one of the biggest concerns or threats is that the incentive of companies to provide these products is sometimes not really aligned with the privacy goals of end users. So in that case, obviously it's Facebook. And so probably most people heard about the, what, what they wanted to change or wants to change the privacy settings in favor of collecting more information about end users, and this largely drives their, their business models.

So in this case, so this news got viral on online media and the situation was not really well received by a large amount of WhatsApp users. So what happened then? So signal and auto messenger, such as telegram, they saw an tum high in the number of people downloading the app.

And, but since then, until then not many people really not in my social roughly was using the signal app. Right?

So when, which was actually quite annoying because I wanted to reduce the amount of messaging apps that I have on my, on my phone. But now I'm really glad that a lot of people converted to, to more privacy preserving to such a signal. So I might be finally able to, to de to delete what's happen in the future eventually, but it also shows that this not to, to succeed. It's actually, your friends need to be also on these applications. So if they don't care about privacy, as you do, you don't, you either don't use the app at all, or just accept that data will be mine and is at risk.

But the switch from WhatsApp to, to signal also showed another issue with traditional messengers. So some of their components still rely on centralized infrastructure. So in case, in this case signal face some, some outages. And so some people might also argue that this shows that it might be prone to, to censorship. But I just wanna say that I believe that signal is doing a great job of defending their users' privacy, or I just wanted to point out that why centralized components can be an issue and why it's hard to move from one message app to another.

Also the account model is different and although they both rely on phone numbers, and then it turned out that these changes, these privacy changes in WhatsApp, they can't be the activity eventually, of course. So it was not that bad.

So in many countries, it would still need to at least to switch a couple of your settings to stay safe and prevent unfavorable use of, of your data specifically in the European union, you will still be protected by GDPR, but after all, I think this news was what was a good thing because now end users became more aware about their privacy and which data they're willing to share in the exchange of their, the services. So I guess it really depends on the use case, but most else would be there as an alternative.

I mean, email can be seen as an alternative, but it's, that's another example of relying on identifiers that are most of the time, not under the control control of the, of the end user, and they're also not portable. And they also sometimes rely on, they also rely on centralized infrastructure. In case of email it's DNS email was not specified, I guess, with keeping in mind security and privacy by design principles, although existing tools are there that can be used to make it more secure, such as PTP or, but they are either hard to use or they just rely on centralized PT systems.

And as a result, we have a lot of spam emails and phishing attacks, which are like natural implications. That's the situation that we have today to deal with every day. So we might need something else. And so did come messaging did specifically provide a great foundation for implementing a form of messaging on top of the ideas.

So it's, and did messaging aims to address these issues that I mentioned before. It's based on a few fundamental principles that you would also get from just using this. So this's under the control of the did controller, which could be the user, and it's not the application that created the account on behalf of the user, such as WhatsApp or slack, for example, and this don't rely on a single total graph to make them actually usable. So the trust does not have to be established by trusted phone numbers.

Instead application applications could issue and verify wherever, wherever order to build a more decentralized approach to reputation and so further. So that mechanisms still exist. But mechanisms exist that allow you to bridge between, you know, these applications and you can, can discover the ideas based on social graphs.

So they, I saw some models where people would use handles or Twitter accounts, or even to, in order to find out about the idea of, of entity. Certain point is about portability. I think that's a really very important point. So that's would allow you to be used out of outside of the context of implications. If WhatsApp signal or slack in an enterprise context, use DDS, then it could easily switch applications and just, you know, bring your account with you.

And this can be used as a decentralized P so I can resolve based on the D ID, the cryptographic information that I would need order to verify any kind of data such as identity at adaptations or authentication events. And lastly, with this and the docs, you would be also able to discover other useful information about the control and G this is more like a technical of com messaging. So what are the, the core pillars core principles messaging is rooted in trust is rooted in DDS and not in the account model of external applications, such as WhatsApp or slack.

And the protocol is secure regardless which transport channel is chosen. So you can theoretically could send, did come messages through email, but most people thought that I've seen are using, did come messaging with H DPSS and some people are using it with Bluetooth. So didn't did come didn't invent their own cryptography. It just uses world class, crypto cryptography and recognizes the latest global recommendations on security.

And the protocol is reputable by default, which means it does not allow a recipient to demonstrate to a third party that the message originated from the sender, which, you know, increases overall privacy and security. So people can still use DCOM in a non reputable way if required. And it also supports onion for more complex architectures also eliminates the signal point of failure by not relying on external centralized components.

And, and again, so it relies on mature specifications under the hood, such as the, you know, IATF specs on, on the stack. And it's not, we don't wanna reinvent everything from scratch. And the standardization happens actually in, currently in the decentralized foundation where we are working on the, the second version of it, the first version was developed in the high blood community. So how does DICOM messaging and DDS relate to each other?

So again, DDS and DD docs are foundational. So you would need your counterpart DD and information from the D the document or to establish such ACOM messaging connection. On top of did send talks is the actual DICOM messaging spec, which defines how to, and secure messages to account party, and also how to discover the transport information to actually send the message. So once you have such a DICOM messaging connection, then you could use something, what you call high level DICOM protocols, one popular example.

One of the major examples include how to issue and request very credentials between counterparties, but the list of protocols is extendable. You can, can even specify your own domain specific protocol on top, which is not credentials related, which can be not credentials related. So how about a basic come flow look like? So this is just you very basic example. It's not economical way of doing it, but you could discover the idea of your counterparty and they are like different options possible. And I think it's just only limited by your imagination or someone's creativity.

So one example would be based on the app domain, and then you would need to resolve the doc to find out about the keys and endpoints of the counterpart. So you can encrypt the message. It actually sent it through the defined service endpoint. And finally, the counterpart can then reply to the sender based the information that was provided in that message. For those of you who are familiar with the did come V one protocol. So what's new in, it can be two, it just uses a more formalized method and relies on open standards such as the, the wholei stack.

And it just also wanted to make it more explicit that it's open to all kind of the DD methods. We, we also have something integrated that is called rotation. You would be able to rotate your DD to another D D during one conversation, and obviously also became much simpler to implement it without sacrificing security. And we will have something like a DICOM protocols registry, which is governed maintained by the decentralized identity foundation. We will be able to register your domain specific, did come protocols this just very quick.

It's just one easy way for enterprises to allow enterprises to discover the counterparty DD. So it's, it's called D sorry. It's called well known DD configuration. And that's back developed in, in the, in the D it provides a neutral linkage between a, that domain and the DD.

So by, by providing the, the web domain like consensus net, for example, you would get the DD of the, of the company. Certainly it relies on the ands, but it could be useful tool to, for the discovery. It just really requires my company to host a simple chase and file under the domain, and that contains them a domain linkage very far credential.

So, but let's talk also about where and how did come, could be useful in an, in an enterprise context for this. I want to also briefly talk about baseline and how the baseline committee might use did come in the implementations. And since this, this track is not only about, you know, S and did come just largely about privacy innovations and baseline is actually another privacy innovation that can use by enterprises, but let's start with what's baseline, actually. So baseline is an initiative which was founded by consensus S and young collaboration with Microsoft.

They spent a lot of development efforts on the first few implementations, and then it was donated to the, to the Oasis foundation. And now it's became a open source initiative.

They are, so everyone is welcome to, to contribute. It's an open source protocol for secure private business processes via the public serial main. So it is used for, you know, private permission system of records that are in SAP or E R P systems in enterprises to allow counterparties or companies to use main net as a common frame of reference. It's important to note that in that case, public is just a middle middleware. So it's not about being a distributed database or being able computer. And it addresses the major concerns of, for public blockchains that enterprises have.

So, first one is privacy. You don't wanna don't wanna store a sensitive data on chain, but it might be okay with serialization of it, like just general storing CCKB proof, for example, and permission. So enterprises usually want to restrict who can add and see the data because there, the actual data is not stored on chain. This problem doesn't really occur and performance. A lot of companies still compare public blockchains with distributed databases, but because the intention of baseline is not to store the data there and just provide a common frame of reference.

This problem can be mitigated and why public blockchains, in the serum's case, it's all this, we have unrestricted access and it's pay use. So you only have to deal with the gas cards that might be required. Use cases that the baseline protocol has again, providing a common frame of record, which can be useful in procurement volume discount and other, other supply chain use cases. And so how to start. So actually to allow counterpart to work with each other. So they typically would setting up a work group and invite other counterpart.

Then they would set up, set up a workflow so that they proof so that they, so that they prove that records in the internal systems match. That's really the, the most simple workflow that people could imagine to ensure that, you know, heterogeneous systems, database S sync, and then after this, they could finally start the baseline records. So update these records to provide, provide command records. So in the baseline protocol, the community has identified a couple of, you know, identity needs. And some of them are how to discover the counterpart, how to can actually see my slide.

I don't know how to obtain the public keys of the counterpart is how to send messages to the counterpart is how to trust the counterparty and how to understand their company relationships. Because someone you want, sometimes you want to interact with, you know, also with subsidiaries of, of, of companies and, and then which they might be used for identity and messaging. And so if you remember the, the did come diagram from one of the earlier slides, then we can see that we could actually see the baseline protocol as a, you know, higher level protocol did come protocol just makes sense.

And yeah, and so in that case, we could leverage DD and very credentials also for the, for the baseline community and baseline, that case would be one example of how you would define a domain specific did come protocol on top of this. Okay. So how would then the workflow look like?

So, you know, so if, if you mentioned that all of these baseline clients would exist, if they upgraded to use Ani an S I, in addition, then you could basically, then companies could basically make the DDS discoverable through. Again, one of the options I, I demonstrated earlier and then companies would get the DD of the counterparties and they would create a working group and then send invites to the DD of the counterpart. And the trust can be achieved through verifiable credentials, you know, by issuance and exchange of credentials, and then verifying them.

And once all that has been done, they could establish a, a did come channel to actually execute the, the baseline protocol to establish this common frame of reference. Yeah. So that's basically it. Thanks for your intention.

So again, so consensus me is now working on MIMO, which is a, this I toolbox that can be used to implement such use cases and thought she was cases. And if you have any questions, please feel to reach, please feel free to reach out on either LinkedIn or drop me an email.