Remote onboarding with Verifiable Credentials

So good morning, my name's uncle Patel. I'm a product manager with Microsoft. We've been working on where fabric credentials, decentralized identity for, I don't know, six years or so now it's been a long time with many of the people in the room. So thank you very much for all the partnership along the way today. I'm thrilled to share with you a key scenario that our customers are looking to use verifiable credential and decentralized identity for solving everyday problems as a place to get started.

And then of course, you've heard from the community, all kinds of amazing things we could do incoming days and years as we saw some of the hard problems as the team from Lisey was describing, for example. So my goal today is to share with you kind of progress what's working today. What are some of the known challenges where we're going next? So let's dive in. I think the tagline is important in this, which is verify ones use everywhere. Our customers today do remote onboarding. It's not a new problem.

In fact, you do onboarding today. Every business that has onboarded anyone today has done this work. The challenge has been, it's not used everywhere. It is done for that one business, as opposed to the internet. And we end up proving time.

And again, what we've been doing. So that result is when we surveyed our customers. 92% of them said they performed some form of onboarding activity today. All of us have been part of onboarding employees, contractors, partners, even ourselves as a subject of it, right? Or consumers, the challenges as we progressively go down that list, the level of assurance or security diminishes. And that's the fundamental fact of how centralized identity systems work for context. I'm on the same identity team at Microsoft that operates one of the words' largest digital accounts system.

And I'll be deliberate to use the word accounts rather than digital identity. We have accounts today for playing Xbox HoloLens, windows, outlook, a billion people do this thing every day and every month we also operate the world's largest enterprise system with Azure active directory, 96% of fortune 500 many governments around the world, including Germany and United nations run on it. But the reason we invested in this work is to address this key challenge around at the end of this onboarding ceremony, we hand over a domain specific credential, a user admin password, a fi key, an MFA factor.

And the fundamental fact of that is possession equals entitlement. We have no idea who's presenting that credential. We just know there's integrity in presentation of that credential and that results in other challenges, like when you try to go to recovery, we have to rely on things like, let me send you an SMS text or an email or ask what street you grew up on 15 years ago.

I mean, just ask Google. Everybody knows where street I grew up on 15 years ago. So this doesn't work and the result is 82% of those same customers go and say, I wish there was a safer, faster, easier way of doing these things. And I'm assuming this resonates with the problems that you guys are dealing with for your own businesses or as a customer, trying to interact with these services. I won't belabor these points because they've been repeated time.

And again, the key difference, however, is there's a regulatory uprising. Now, in addition to the end users being frustrated, which is GDPR did a good first start, but now just like we have data protection laws. There is identity protection laws being enacted such as the European union digital identity initiative, but the same is happening all over the world. And as I described a large set of customers that we deal with, they are in various parts of the world.

And there's no common way of dealing with data, residency requirements, permissions, consents, et cetera, which would result in a very horrible user experience. So we think we could do better using an open standards based approach. And that's what we've been working with the community on. So next I would like to show you a demonstration of what that could look like high wire live demo in a conference setting. So we'll see how that all plays out. Is are we able to switch to this display? We are not able to, okay. Failure one.

So I'm going to do the following instead of belaboring, the point we would have, how many of you have here seen issuance and presentation of verifiable credentials? There's no one left in the room who has not. So we're going to spend time talking about what could be different about it as just li users showed you. You could have credentials being added to your wallet. In our case, we're extending Microsoft authenticator. Microsoft authenticator is used by a hundred million people every day for doing enterprise authentication events or consumers.

For that matter, what it proves is you have a secondary factor do say that you can't just fish my user admin password, right? So it's easy to use and secure.

However, it is not verifiable verifiable by an independent party. You can trust your own domain for your own company, but how do I know that you are the same person? And that's the reputation score thing, right? It comes from outside by definition. And that's what verifiable credentials enables us. In this case. What we've seen in the demo is wood Grove. As an employer, would've issued you a credential that says I'm a verified employee of this company and that you could have received by showing up in person presenting documentations, showing a selfie or a driver's license.

Everybody has done these flows. Now what's di that's not the interesting part. The interesting part is this credential is issued against a cryptographic key, a set of keys, which are only on this device. They were protected by your biometric or your pin, right? It comes with its own set of challenges on how do you roam these things, how to recover these things. So I'm happy to do a deeper dive with you offline about it. But as a result of the user, having this kind of credential, they can now present it to anyone.

And so far, there's nothing different than anybody else who has built a decentralized identity wallet in the community. The part that we could offer to the community is based on that interoperability, the millions of apps that run on Azure active directory now, including all the first party apps of Microsoft can accept this credential without having to set up custom federations. How many of you, I know David's here. How many federations do you set up, man? And how many nights do you stay up with life site issues, right?

That's just a problem of the current centralized systems on being able to define custom attributes and schema and being able to scale such federations is not easy. Versus in this scheme, you can go right, two lines of open ID, connect, call, and request any verifiable credential from anyone on the internet. And this is not a pipe drink. This is working. So this demonstration with I would've shown you normal flow for 90 seconds, and I'll send you the website to the demo.

You can do it with your current authenticator can be implemented by anyone in five hours, not rocket science, it's six API calls, right? The net result of it, however, is a far more transparent and convenient process of managing such credentials. When we grant these oat consents today, how many of us know what we have consented to blessing and curse of GDPR is we have been trained to just click on, okay. Somewhere on the dialogue box, there's an interstitial in my way from reading the article that I want, click, okay, move on right today, we are on Wednesday or Thursday.

There's no way to even know what websites you've been to forget what data you gave. How many of us remember how many websites you've been to, and then maybe find the button for GDPR export or delete. And then maybe the data that I give you makes sense to you.

How many, if you have actually tried to export that data and look at that information and how much did it make sense to most of us, there's zero hands up, right? And so it's not very transparent nor convenient versus in this world because I am the not only the presenter or holder of this credential, but I am also the controller because I hold the keys to present such a credential.

It is convenient for me to track therefore, who I have given what permission to, and I'm deliberately using the word permission rather than consent, because consent is delegated to a third party, like a centralized identity system, Facebook, Microsoft, Google, right? Remember a few years ago we had that Cambridge Analytica thing. How many of us remember we actually granted consent for sharing political preferences versus took a quiz, no way to prove it the only way. And they did a congressional hearing to figure it out.

Couldn't figure it out because the only person knows an it admin in Facebook who could update an application ID mapping either they did it or security flaw or whatever it is, but no way for a user to know what happened. Versus here, I have a cryptographically signed receipt with me that I can present to a regulator or the relying party, the application, or the issuer to say like, look, these are the permissions and our exchange of values, nothing more, nothing less. So we think this is a more verifiable, transparent, and convenient way to present credentials and manage permissions at scale.

How does it work? This super simple illustration? The first thing you should notice with this picture is this does not depict reality of today. Today's reality would be that issuers in the middle, the user is on the other side, hence consent. And we do talk about as software engineers for a long time user centric design, but it is not right, like to do this, to do this picture. What we need to do is have two keys, just like in a bank today, we have one key that one key is given to us loan lease by the centralized identity system like Microsoft.

And you get to use it when Microsoft is online or any other system provider is online, or it could be turned off either because of policy change or security that does not live up to the values of Microsoft. Like our mission is to empower every person and business to achieve more. Not when we decide not when we choose you are the right 2 billion people on the planet, right? Therefore we are taking this investment super seriously. And the technical manifestation of this is a two key system. One key belongs to the issuer. The other key belongs to the subject.

Both keys must turn in order for a credential to be validated. Now, when I go present such a credential to an application, they can independently verify who issued this credential. I don't have to trust a user. And on the flip side, an issuer can revoke such a key at any time. So I know if this credential is currently valid or not, I can hold an expired driver's license. I can't drive, but it still works as an age proof I can present as expired student license. I may be an alumni member now, for example, right, for the user, only the user can present this thing.

Nobody else could pretend on behalf of the issuer, like the Cambridge Analytica thing. Only the user's key could have presented this credential. Now this allows for a whole bunch more scenarios. Now what makes all of this possible is having a support in the bottom layer for resolution of these cryptographic keys. And we call it plural deliberately. You can choose any substrate you like in our case, we have implemented it against did web, which allows you to anchor that D ID document of your cryptographic key, the mapping of your key and your identifier on a web server that you own in control.

If you like to get started there, cuz a lot of the enterprise customers that deal with there are like, I like the blockchain stuff, but I have no idea how to do compliance and security of that. Especially as a shared resource that I have zero idea about what to do, but decentralization pattern does not require you to use blockchains. What it needs is just decoupling of issuance and presentation or verification, right? So you can achieve that pattern with existing infrastructure technologies.

Now it has some benefits though, such as timestamping and lineage and change control, et cetera, in a more auditable, transparent manner. So you can progressively go there. So our job, as we've done with other enterprise customers enable you to have good choices. They're still safe, secure compliant, but there are trade offs as with anything else. But the important part is going towards a decentralized model that gives you a better scale in a more African system. So there's an alphabet of alphabet soup of specs that are involved in our implementation. I won't go through every one of them.

There's been deep dive topics and discussions on these topics throughout the conference. I'm happy to go discuss with you offline and present even documentation around it. But in shorthand, the, the, the big ticket items are it's based on decentralized identifiers. The format is verifiable credentials. So then it's, it's not custom put interaction. There's one payload.

If you will, the protocol for requesting and verifying these things is open ID connect, which is what 96% of applications on the internet speak already, therefore going and telling an existing application developer like two lines of code change. Instead of asking for an note token and ask for a verifiable credential that could work. What we have implemented is a managed implementation of those set standards. You don't have to use any of it. You can use open source implementation of it to implement your own version of this.

If you like, and our documentation will point you to the open source repositories of it, the issuance protocol has an interface to it as well as APIs and the end user is built into authenticator, as I have said in our case, but again, you can go build your own wallet. If you like will be extending this stack to support E U D I, for example, the European digital identity initiative and be participating in pilots, there are similar ones happening all over the world. So the intention here is to provide a consistent developer and end user experience.

And we will keep up with the changing landscape of standards and interoperability and the rest of it for our customers for community developers will partner with you on interoperability. In that same sense, we partner with 10 leading identity verification partners. They can issue to get started a whole bunch of credentials. This includes doc identity documents from around the world, including the governments directly. There's a bunch of system integration partners who can accelerate time for you to realize this value for yourself.

So if you want to issue your own verified employee card, a loyalty card, a student ID card, faculty travel friendship card. You can mind any all of these on your own, right? So we're providing Israelis. We have no visibility or insight into what is happening. Cause the service we've implemented is a stateless service. It has no persistence. Therefore it can talk to your existing on premises, identity system, a SQL database, Oracle, whatever AWS, Google doesn't matter.

The key scenarios we've found most res resonates with our customers are on onboarding that we've talked about, but also onto things like securing access to applications. Instead of asking for one factor, you can now ask for credentials from multiple trust sources for a given business process at hand. Sometimes you wanna verify training. Sometimes you wanna verify health status, these require different policies and implementations today, as opposed to a common one API to request and verify any of these credentials, finally recovery.

If you can use that credential to do onboarding such as that foundational identity document that we were just talking about, why can't we use it for doing recovery as well? These are some of the flows that we support today in Azure active directory, we'll be extending enhancing those to enable verifiable credentials as an option. You can continue to use old tokens and Fido tokens if you like. But we think for cross domain verification, verifiable credentials is probably the best choice. We think finally, this enables a more trustworthy, faster and cheaper way to verify.

There's a bunch of case studies NHS guys yesterday got recognized for this work in partnership with our bodies from ever for enabling staff mobility. These case studies are public Cayo universities using this for student ID cards and faculty ID cards. But more importantly, it's not just for themselves. They have enabled partnerships with JCB and a bunch of others around the Japanese ecosystem where the student ID card now is a privilege or entitlement that goes beyond the campus boundary. Government of flounders is looking for this in order to enable citizen ID services.

E-government extending beyond government services though. Quickly start a business. For example, it could use for many other things, a bunch of resources. I can send you as part of our presentation text, but hopefully that gives you a quick overview and I wanna make sure we're on time.