The impact of decentralized identity solutions in the marketplace, insights and lessons

Here at NDCO. As we support enterprises organizations from around the world who are implementing decentralized identity or verifiable credentials to create trusted digital ecosystems companies come to us in all phases of development, from idea all the way to supporting a commercial product. And they usually come to us with really difficult, challenging, complex problems, because that is what we specialize in solving for organizations moving in the, the direction of using verifiable credentials.

Specifically, the majority of our customers come from financial services, health IOT, and the travel sectors. But Ken and I have both been working in this space myself for almost a decade and Ken for almost as long. And for the past, I think four or five years we have actually worked closely. And what we're here to talk about is some of the best practices that we have developed and that our team at NDCO share with our customers in helping them succeed in this journey. So today we're gonna talk a little bit about why do digital identity and its evolution.

We'll discuss some of the fundamental identity concepts we're gonna talk about, did components. We're gonna talk closely about closed ecosystems, open ecosystems. This is the piece that has really helped driven idea implementation and scale quickly. And so we'll spend some time there, but when it comes to scale machine readable governance, and this has been developed in the past two years, specifically for our scaling customers. And then we'll take a look at some market opportunities.

We all, we all know this cartoon from the new Yorker magazine. You know, the fact is offline identity depends on physical documentation. And here we are 2022. And the fact is your identity Carter driver's license. And that passport book is deemed is more trustworthy than any data that you share on the internet. How many times do you put something in? And then you're still asked even sometimes to send an email copy of your passport or driver's license. We won't talk about the security issues or in the us because of HIPAA.

You can't, you know, share medical documentation on the email. There are all kinds of issues, but the fact is it's still that physical document, even if we're taking photos or faxing it. And so why is it it in 2022, that, that physical document remains more trustworthy than the data we have online. You think about when you go to make a purchase, let's say you were to walk into any kind of apple store or computer store. And you were just to say, oh yes, I wanna pay, but write this down, type it in. And you just give your credit card and the expiration date. They're not gonna take that.

But you think about it. That's what you do online to make purchases. So there is this disconnect. And so when you look at the fact that you have this physical documentation and that you can't use it online, the same way that we use in our physical worlds, that is exactly the problem that we solve. And we are going, we're, we're gonna skip over this video. But if you get a chance, that's actually really funny. And I laughed so hard.

I cried, but this was a video that came out about a year ago. And it's a court in Texas where the judge actually had a cat filter, stuck on him. And he kept telling the judge not the judge, the lawyer. And he kept telling the judge, I'm not a cat. I'm not a cat. And the judge said, well, we, we trust you, but really I, we know this is silly, but the question is, he kept saying he wasn't a cat, but you know, how can we verify that? And so when you look at zero trust architecture, one of the key principles is trust, but verify lots of architectural ways to solve the trust.

But how do you solve the verification? That's precisely what decentralized identity and verifiable credentials do. Why do verifiable credentials advance digital identity?

Sometimes organizations think I have to rip out my legacy system, or I have to replace federated identity in order to go this traction and absolutely not decentralized identity and verifiable credentials actually can extend your business can extend federated identity can allow for more reach, can allow for you to obtain data and information without a direct integration from other industries or companies that you may not otherwise be able to connect with.

And it allows your customer, your consumer, your employee, a device to share more information with you than you otherwise would get, and what type of information can help expand your business. So when you look at where we are and the limits of what we can do with identities to propel our businesses, it's often because you have the identities or information that's controlled by large organizations that you may not have direct access to passwords and logins are the being of our existence.

Right now, it's hard to find ways to scale the technology and prohibit forgery. And how do you build these trust interactions that are automated without creating bulky, centralized trust registries It's Heather? I think it's important to mention that these solutions that we're talking about integrate with their existing solutions so that there's not a big, complicated ribbon replace strategy.

It's more of a, an evolution rather than a revolution, even though the technology is revolutionary, it can be slowly integrated without totally turning a company on its ear, trying to figure out how to, how to make this one time leap. It's more of a step after step. Absolutely. And I'm maybe Ken, you can walk through the legacy systems and talk a bit more about how we do that. Cool.

The systems today are mostly centralized and owned by the company rather than the individual that these accounts are created, or identities are created with an relationship with an existing provider, but that's in a single domain. As we look at how internet ID works today, most of the identities that you have, you don't own, you don't control it. You can help create it, but it stays with that company. They own it. And they basically make all the decisions about where that identity can be used or how it can be used.

If you look at multiple companies, the same process is replicated throughout those relationships. So you have a duplicate identity. That's been created with many different companies like LinkedIn and, and meta, no matter where you go, the, those organizations typically own the account and then you can't take it. It's not portable. And it's not something that you can easily make interoperable. Some companies have provided federated identity to help bridge that gap, but it's still a complicated mess with decentralized identity.

The, the holder of that identity, the person who has that identity is the controller of it. Whether an identity is issued in the form of a credential to that holder, they're the ones making the decisions about the interoperability.

If, if all the companies or organizations that they want to share with, or individuals follow the same protocols, they make it capable of having interoperability without direct integrations, the same standard transport or protocol did com type protocol can allow for the sharing of that identity in a very secure way, without having to do direct integrations between an N way integration between all the different parties. And I think that's a simplification of how it works at the same time, providing better security.

When the data is transmitted, A trusted digital ecosystem takes that ability to solve that problem of fraud or fake data and, and allows for trustworthy data to be passed between the different parties. An issuer is the one who creates the, the trusted data in the form of a credential. They sign that credential and give it to the holder. The holder then has it in their possession, and they can choose to verify with any verifier who wants to look at their data or needs to see their data.

And they can do this in privacy, preserving ways, by doing things like selective disclosure, which means you only reveal a certain set of attributes that are in the credential or with predicate style proofs. Those are things like saying my age is older than 21, so I can rent a car for instance, but I don't have to give you my exact birth date. When that presentation occurs over a secure peer-to-peer channel, the verifier can verify the, the accuracy and the issuer of the data.

They can do that because when, before the issuer gave the credential to the holder, they anchor their did or decentralized identifier. The thing that allows them to issue a credential, the schema and the keys and so forth that are used to create the credential. They put those on a, on a distributed ledger. They can be picked up by the verifier from that ledger without contacting the issuer directly. And then the cryptographic methodology can be followed and, and verified that the issuer is who they say they were.

And that the data hasn't been tampered with in route, and this allows the businesses that governments to solve those problems of, of anchoring of trust and authenticity of the data. And the fact that it's tamper evident if somebody were to do anything, to change any of the fields in, in the credentials that they share, and that allows the, the whole ecosystem to exist in, in scale. And that's one of the things we're gonna be taking a deeper dive into is that every single implementation that we work on is a complete ecosystem.

We work through with companies to define who their holder, who their verify and who their issuers are. In fact, I mean, I think a lot of organizations that we've worked with started that all three roles sit within the company. And here's what it looks like.

Yeah, closed ecosystem is my favorite way to start with a, an organization that's trying to get into decentralized identity by having a closed ecosystem. It means that they control and manage all three parties.

They, they don't have to fill all the roles they fill, typically the issuer role as the company, their employees, or their customers are the holders. And the typically the company themselves, or one of their trusted partners is, is the verifier of the data. But it allows for more simplistic approach rather than saying, I'm just gonna be the issuer. And I hope that somebody will provide the, the holders or people subjects of the credentials and that somebody else is gonna want to verify the data. If you take that approach, you may or may not be successful.

If you fill all three roles, you're guaranteed that you have a mini closed ecosystem that allows you to get started with a prototype, roll it into trial, or then production eventually after you've proved out how it's working for you, and then scale that solution to meet all of the needs of your customers and perhaps your partner organizations as well. So, Ken, if you're looking at this image here, why should someone who hasn't seen this for this first time, not feel overwhelmed?

One of the reasons that you can feel not overwhelmed is that Inco can help you with all of the different agents and software that represent the different organizations. And so your role is simplified to deciding what type of credential you're going to issue, and then walking it through the, the, the software that takes care of the necessary creation of the agents or holding the credentials or the, the issuing and verifying parts of it.

We even operate a, a network or a ledger that allows for the, the credentials to be anchored and validated in the verification process so that you don't have to, to start and write the software all yourself, or try to figure out how it all works and deploy this solution on your own. We kind of guide people and organizations through that process from education and training all the way through architecture, the software creation and deployment and scaling and, and all of the issues that occur along the way you could do go on that journey on your own.

It is available to you to do, but we try to make that, that a less intimidating process and help people get started without having to become an expert on day one. You can gradually pick up experience and skill and get to a successful deployment with all the necessary bits that you need in order to be happy, Right? Like the mobile agents, mediator, cloud network, all of those are available. Open source, you vendor agnostic, you have the ability to go build what you see here today, the code and the libraries are available to you.

And so in open ecosystem, what's interesting in our experience is we've worked with customers and the thought is I'm gonna have a closed ecosystem for six months or a year. And then one day I will be the point and I will open it up to my partners or other customers, or those who want to participate with me. And usually what happens is they haven't even finished building the closed ecosystem. The partner starts showing up and wanting to get to create an open ecosystem.

I think we see that again and again, And once you have the framework in place, you can expand the number and types of credentials that are supported as well to other use cases because the agents are gonna follow the same protocol. And you don't, it's not a big effort to extend beyond the, the initial credential or credential set that you've defined to quickly expand that. And one of the things there are companies and industries out there who are developing to this space.

So when they hear that there are others available that they can partner with, they start reaching out and developing use cases together, which is really interesting machine readable governance. Let's talk about what that is done to help propel an open ecosystem. Machinery to governance is a, a methodology for defining the trust rules and the actions and the CHES that might be used that define what type of credentials you have by putting this into a form that that software can interpret the rules. You don't have to have a human look at every single credential and make a decision.

It can be automated and, and expanded by setting up the machinery governance to define the, the rules that would be followed in your mini ecosystem, that you've defined your closed ecosystem. And eventually your open ecosystem, you can determine and make changes to the behavior. Who's a trusted party, and what are the different credentials that can be exchanged.

And the, the rules to of what's a, a legitimate thing to ask for as a verifier, as a verifier at a, a grocery store, you don't need to know my entire medical history. You may need to just know that the government's approved me for credit, or that I'm a legitimate business that can purchase from you, but I, you don't need to know all the details. So you can say only I'll ask for specific things, and that allows you to, to grow your ecosystem in a dynamic way, without relying on a centralized thing, like a trust registry for accomplishing the, the definition of who to trust in your ecosystem.

And this was specifically developed out of our work with C a and the government of Aruba when we started off issuing health them credentials. And that's because when you look at scaling with governments, they wanted to be able to make their own decision independent of a centralized trust registry authority. They wanted to be able to quickly change that decision. Sometimes it changed multiple times in a day, and they wanted to be able to scale quickly. And so that was really the impetus and also how this was development tested as well.

When you look at where we, where we go with customers and organizations, what I love about this approach can, is that you start simple and then look what happens. And the starting simple gets helps overcome some of the technical and business decisions that often impede you from trying to, to get started because you can start small the cost and the scope of what you're trying to do is, is limited. And so you're more able to contain all the variables that go into setting something up like this and keep it in a simple form while you prove it out.

But as soon as you get it proved out, that's when the, the excitement starts to happen, because you can simply add in additional people to become verifiers or issuers in your ecosystem and add additional types of credentials that a holder can have. But soon as other ecosystems near you see the valuable types of data that you have, your holders can bridge the gap without a direct integration, just using the same standard, open source protocols to allow for interactions between ecosystems and that network affects soon builds and allows for opportunities for ecosystems to coexist.

And interate because you don't have to have a central organization that controls it all. You can have these ecosystems that just interact based on the protocols themselves. And when companies come to us who are just moving into this space, oftentimes they do feel overwhelmed in the sense of you have to boil the ocean in order to make this work, or they start with how, how is this all gonna work? And they're just thinking so big. And that becomes really hard to see how you can succeed, how you can integrate this with your organization and partners.

But the diagrams that you see here, we've removed the names for privacy purposes. But these diagrams weren't just made up. These are actual ecosystems that we've supported and helped grown today. And this is how they're operating. And you can see on the constellation side, you've got different industries, exchanging verifiable credentials amongst each other. And that happened more quickly than I think any of us thought, but it happened almost organically. So you're boiling the ocean, but you don't realize it until you sit down and start drawing out. What's actually occurring.

You boil the ocean one drop at a time, and that's the benefit. You don't have to do it all in one, in one fell swoop, you can do it incrementally. And that's the beauty of it. And oftentimes it's the governance part that becomes the most part of the impediment where organizations will come and feel like they have to go to council with these huge, massive governance documents, which they know will black hole, or it will take their council's office weeks or months. And we've had organizations come to us with that as the blocker, the approval on, on a large governance document package.

So oftentimes we start talking about how do you start simple on governance and then scale from there while still supporting the, not only the technology, but the policy stacks, The, the technology stack is often where most people focus their effort. And although the technology is deployment worthy and, and ready to operate in the real world, not everybody thinks through the, the process of how to get the governance going. The beauty of starting with a small closed ecosystem is your governance is less complex.

And so you can put together your ecosystem governance framework, that is a less intimidating set of documents to, to manage. And then the implementation of it. They don't have to have people doing the implementation. If they can express that as a machine readable governance, they can have the software take care of the implementation parts of the governance without having to get everyone in the entire world to agree on, on what that governance policy is going to be. You can in a closed ecosystem, you can define it yourself.

And then as you expand it to open that up to other partners, you can add them in incrementally. And so it, it makes the whole process a little bit easier. It also helps with the fact that if you're working on a network, such as the NDCO network, that's already worked out some of the policies at the layer, one, the how to run and operate a network. That part can be used as foundational. And you don't have to worry about that yourself.

You can worry about the layers that are, are applicable more specifically to you at the ecosystem governance level, the compliance with GDPR and some of the other privacy protection things are taken care of by some, some by the software itself, because it builds in some of the privacy preserving aspects that make it easier to comply with those global data regulation policies. And that helps support a complete effort to have a whole solution. That's not only software and technically sound on that side, but also is in compliance with your regulations and the governance side.

And what we found with in DC, we like to call it B Y B bring your own blocker. And one of the blockers people bring to us is the project that they were working on, got blocked in council, and where we've worked is said, okay, let's look at a closed ecosystem. Let's simplify it. Let's simplify your GU, your governance. And that has removed the blocker. We had one large industry organization that had been blocked. And in that meeting, we, we support and go to these meetings. We go and meet with lawyers, et cetera.

And we, I think we were prepared for at least an hour long meeting. It was done in seven minutes. And so that's, I think shows the power of simplification and beginning with that closed ecosystem, because it also proves success. And so companies can continue to grow the solutions that they're building. And really, I think, you know, we talked already once about machine readable governance, but I think Ken, this has been for our experience in the last two years, a huge driver of companies moving from like original POC demo to an expanded pilot with multiple parties. Yeah.

I think that, that that's made a, a great difference because of the, the, the simplification that it offers to getting started. It allows for that governance framework to be put into a, a, a file that allows for the, the easy discovery of what the rules and conventions are, so that all the parties know how to behave.

Well, it can identify the roots of trust easily by specifying who are trusted issuers and those roles and permissions of I'm an issuer, I'm a verifier. And, and those need to be made available to show what the, the acceptable workflows are within your eco ecosystem. You can also have ad hoc interactions that don't fall within the governance. And that's, that's a flexibility that's there as well.

But the ones that you've defined is interactions or workflows within that machine, readable governance, the software can assist and make the path a little easier for the end users to know, Hey, this is a trusted verifier. They've already agreed to abide by these rules. And they're following the, the guidelines for what they should be asking for. They're not asking for too much information and, and possibly putting my identity or my data at risk.

The, the thing I like about the governance files and a as an advantage over a trust registry is you don't have to have a centralized authority determining the rules for your organization. If your government is, has its own local jurisdiction, it can make the rules that apply the law and the rules that are need to be abided by in that jurisdiction.

The, those agents can still interoperate with other jurisdictions and find out what their governance is, but that allows for that system to discover the governance framework, and then be able to share those governance framework files easily. One of the, the benefits is that the rules are well known. They're not held in a, by a single player. It's not a black box that no one can understand. It's available to all the parties that can download it. They can figure out how it's supposed to work.

The issuers and verifiers can use their software to help make sure that they're behaving according to the policies that are defined in the machine, readable governance, the issuers and verifiers of the organizations. Typically the end users are the ones holding the credentials, but the software can also assist them to know this is a trusted issuer. They're in the governance file.

You can, it's worth getting a credential from them because everybody else is going to trust that credential. You're not getting an ID from Bob's fake ID organization, selling fraudulent IDs.

You know, you're getting it from the right place. You also know that a verifier is a trusted organization as well. So you're as a holder, getting the benefit of the software, supporting you and guiding you through the interactions. And that helps the users feel more confidence. The offline implications of machinery governance are also very important. Not every place in the world has awesome internet connectivity. Sometimes the connections are spotty, or you don't have a connection at all.

By having a machine readable governance file, you can support an offline interaction as well, because that data can be cashed locally in the, the agents that are participating and you can still interact without having to phone home to a centralized trust registry, to, for every decision that is going to be made. They can be made with the software locally on the agents that are interacting.

And that, that removes a, a dependency and offers the flexibility of interacting and in a trusted way, even when connectivity may be limited. And one of the areas, those who are joining us today, you can learn more about machine readable. Governance is Cardea dot a P it's with Linux foundation, public health. It is the project that C a donated their code from their work with the government of Aruba to. And although when you go to the website, you may say, my use case has nothing to do with healthcare. That's fine.

There is a lot of resources about machine readable governance that can be applied to your particular use case and problem there. And as well on the N D C YouTube channel, we have meetups and videos that go in depth, spend an hour just on this topic. And there's also code available that folks can go to and review as well. And so we have tried to make this as open and transparent and tools accessible as possible. So folks can learn more about machine readable governance and how they can apply it.

One of the things that we've learned is, you know, we've, we work in building really cool and awesome technology, but Ken and I know the technology is only as cool as you can communicate it to others. And oftentimes in the planning of a POC or, or pilot, even moving to market, the part around marketing and message gets ignored, or you get to a point and then you have to bring your marketing and comes teams into it.

And they, this is brand new. They have no idea what may going on in, in the research lab. And so that's something that we work with organizations on is how do you bring your marketing coms in early, and how do you help educate them along the way of what you're doing to solve problems so they can help you not only communicate to the outside world, but specifically communicate to the multiple audiences internally, or even within your consortium, that you need to explain things to you.

Because when you're going out to trial this with, you know, your average customer, you have to be able to communicate with them. Why would you wanna download this wallet app verifier? Or it may be an organization who has to deploy this and their tech team has never heard of this. And so I think Ken, what we've learned is just the extreme importance of communications yeah.

Internally to between the, the people inside your organization, whether it's communicating it to the business side of things or the business side, trying to communicate it to the internal marketing organization or the finance people and explaining how it works. That's all part of the communication strategy that you need to take into account in order to effectively get the message out to everyone who needs to know, not just single audience. So there's multiple audiences and communicating it out, shouldn't be as complex as some people stumble over it.

So we help people craft those messages and help them simplify the message so that it is understandable by all the parties. And we actually plan the communications with sprints. And so we all know the typical tech sprint, but we also have a com sprint.

And so if you are developing in this space, we highly encourage you to develop a com sprint with your marketing and PR team with your social media folks, and do that simultaneously because, and do joint meetings between the tech teams and the marketing and coms teams at least once a week, or have them join at least one standup every week we've found, this is something that we do not only internally with our own company, we do this with our customers. And I think Ken that's one of the areas that we feel most proud of is how well the comms PR teams work with the tech teams.

So when we finally get to that milestone, we're ready to go on, on both sides. Yeah.

Our, our internal team is very used to that close interaction to, to make it happen. But sometimes our customers need a little assistance getting over the hump and figuring out how to get the technical message communicated in English that business people and customers can understand it, to make it, to, to see what the value points are and what, what the value proposition is going to be. So that everyone's on board. And I should also include in that in the com sprint is also, we roll up business development and sales into that.

So we, you know, I encourage everyone here, who's planning and working on verifiable credentials. When you plan your tech sprints plan, your communication sprints, right.

You know, same document and your business development, sales sprints, because for those who are on the biz dev side, who have never had to sell these solutions, it's really important to bring them along and have them plan their outreach at the same time that your development is happening. Use cases. First of all, use cases. There are so many, once again, it's boiled ocean type situation. We see you name the sector, all types of issues, but where we see some of the emerging use cases that are in commercialization or heading there, finance, KYC, tremendous amount of work going on there.

I think the, the technology itself also enables things like proof of age to, to exist in a way that hasn't been available easily in the, on the internet. If you're self attesting to all your data, you can be whatever age you want to be. But if you can share that age in a way that's both privacy, preserving and trustworthy, then you have a mechanism for avoiding legal hassles or, or issues with selling products to where there's age restriction in place. Or there might be legal liability for interacting with minors or things like that.

And that allows for that trusted ecosystem to provide the foundation for the interactions to occur in a way that is more compliant and with law, and also in a way that can be audited and, and fully allow for the, the verifications to be done in a way that can be tracked in, in, in a, in a legal framework. We also see advancements being made in travel, not only air, but ground train, any type of transportation and not only commercial, but also we see this for shipping and other types of transportations of things as well.

I always find that when you look at actual what other companies are doing, it can be inspiring even if you may not be in that industry. And I always see the best sense of inspiration and innovation is taking an idea from one industry and applying it to the industry that you're currently working in, in the finance bonafide, who works with the credit unions around the United States. They're specifically working on the KYC.

What's also interesting is ATB financial in Canada also has a number of publications in one award for their work Wednesday night, as well on KYC processes, liquid avatar technologies. They are also out of Canada. They're working with Ontario convenience store association on the purchase of a restricted products outta convenience stores. And that's very fascinating because I think there are many principles and approaches to the proof of age that can be applied into other use cases.

And then in travel C a we were thrilled when they won the E I C award Wednesday night for their work on verifiable credentials. And although they started specifically solving COVID health problem, that has quickly emerged to a foundation that they're applying to other challenges in the, in the travel ribbon. Their goal really is Adrian talked about Wednesday night is having a vision of no lines. And I'm all for that goal. I think it's interesting, as you mentioned, the, the travel use case, Heather, that that identity is not just for humans.

There are other, other things that need identity as well. And you can assign identity to IOT devices or organizations or objects like items in a supply chain that need identity as well.

And, and that's another interesting aspect of, of looking at the decentralized identity. We see this in green energy climate accounting, that's another area that is working with verifiable credentials to help connect the data to the sensors. Yeah. So an OT device that, that measures the emissions at a, at a factory or something like that allows for the data to become trusted and recognized. And you can see that the T devices actually signed the data in a credential. And you can track that as well as tracking using identity to establish who a person is.

You can also use it with an IOT device or other type of sensor. I think what's important to explain is that we've been looking at this for so many years as an emerging technology or vision, or maybe ideas on slide decks. But we wanna explain for those who may not be in this space is these solutions are being developed today. The technology it's available now, and they're developing and going to market, this is not a something five to 10 year range anymore. This is between six months to a year. And some organizations cases.

I think there's gonna be a significant surge of solutions in the market in the next year to a degree that we've not seen before in this space, Because the technology is fairly mature. It's not the limitation of the technology to get you to market. It's typically your own organization. Being able to move fast enough to adopt and apply it to a specific use case and integrate it with existing solutions.

The, the, the gating factor is not the availability of this technology nor the governance that goes along with it, that those are solvable problems and a rapid deployment can occur if your organization can move and adopt it quickly. But the, the technology is not the limiting factor. And now there are multiple ways to engage with the technology proprietary platforms, open source code. You have many different ways in order to start developing now, even compared to year or two years ago, we have some more use cases here. Metaverse common, common every day headlines, right?

But there's a lot of opportunity for identity and verifiable credentials account openings. Another one that we see proof of age, because there are some gated metaverses where they wanna make sure that they have only those over 13 or over 18 participate. So we also see financial transactions using verifiable credentials for proof of account ownership. Healthcare did come. This is an area Ken, that I know is one of your specialties. So healthcare is, has an identity problem because it's difficult to get a solid handle on patient identity by introducing a decentralized identity for patients.

It allows for things like telehealth to become much more readily implemented, because you can know Can, sorry to interrupt just to let you know, we have about seven minutes left of your time. So we might wanna leave some time for questions as well.

Okay, great. Well, that's move, move rapidly onto the next section, which is questions sections.