 Okay, it's 1050 Pacific where we are in Arizona. Welcome everybody and good morning to those here. I know there are people from practically across the world participating today. It's very exciting to see. We saw a lot of presentations already in these day and a half. I hope you caught a replay of Vitalik's interview with Brian. It was also fantastic. So let me jump on to what we are going to talk about today, which is the use of verifiable credential technology with our loyalty application. So in previous iterations of this, we had presented a year or two ago about the use of hyperledger fabric to build a consortium loyalty product. That was our first foray into using fabric. And I'll talk a little bit about our history and quickly where this product came about. And then we will layer in the second problem to solve, which is how do you securely store customer PII data, use it, but at the same time, don't fall into all the pitfalls of existing systems. Pretty much the biggest companies in the world have not been able to secure their customer information. We have seen that time and again. And maybe there's a new way to think about it using verifiable credentials. So that's what we will talk about today. And I have a quick two or three minute demo, which kind of illustrates the concept. I'll go through some slides and then hopefully the last 10, 15 minutes we can spend doing interactive Q&A. So please do post in the Q&A section or the chat and then happy to answer as many questions as possible. So who are we? Praveeti, which is a company that we founded in 2013. Our main focus was CRM and loyalty. And just very quickly on our history, we had worked a lot with loyalty applications with large airlines and so on and so forth. And the thing that we learned from our experience consulting with these companies and enterprises is that a loyalty program can be very profitable under certain situations if it's a consortium loyalty. Airlines are the best example that you can think of. But one problem that happens is these loyalty programs make a lot of money selling a ton of points to partner ecosystems, credit card companies, car rental companies and so on. But the problem is one of reconciliation. There's a lot of point to point integrations that we have done personally as part of our consulting assignments. And then reconciling becomes a lot more difficult with the onset of blockchain technology. We thought that one way in which we can mitigate a lot of those types of problems is to use distributed ledgers. So with that in mind, we were at that time working with a big automotive OEM trying to help them stand up a loyalty program. And then we proposed this idea and it was well received. We did an Ethereum POC just to kind of see how this concept would work. And then again, we have talked about this in other sessions here even today. We switched to fabric because of its enterprise friendly nature, the cost, gas cost and things of that nature, right? Which were barriers at that time when we were looking at this. So we chose fabric and it was a great choice. And we delivered a pilot for this particular customer. So our product has grown out of that. And so basically our core product, loyalty product was if you have a consortium and you have some large partners and small partners, the large partners will run some notes which will help us reconcile, get invoices quickly reconciled. As a matter of fact, Professor Mary talked about the invoice reconciliation problem with Walmart today morning. And similar situation arises when you have a large set of partners trying to resolve the point balances that they owe each other. So that's the core product. But today we are going to focus on another aspect. We also got the opportunity to be part of Hyperledger, talk to companies like Avernem who are pioneers in the area of fabric in Aries and Indi. And then we said, why not take these additional concepts and apply it to the area of loyalty? So as you know, one of the biggest problems that I just touched upon that is the fact that customer data today gets stored in central CRM databases. We have been working with CRM for the last 20 years and this is a constant issue, right? How do you securely keep that customer data prevented from getting hacked? So in the context of building our loyalty application, we thought why not do this, right? When a customer signs up for a loyalty program, you collect some information about them because you want to serve them better. You want to know their address, their email address, their zip code maybe, and a few other demographic information the month they were born in so that you can give them a good deal that particular month and so on and so forth. That's a typical loyalty system, right? But instead of storing that data and have the potential of losing it and being subject to all sorts of fines and not to mention the dissatisfaction of the customer, why not store it as a verifiable credential in a mobile app? Typically loyalty programs carry a mobile app, so why not store it there and then seek the permission of the customer if you ever need to get one of those attributes for you to use and this way, even when you seek the permission and use that attribute, you are going to use it fmrely and you are not storing anything, definitely not storing it to the blockchain or for that matter anywhere else besides the secure location, probably secured through a fingerprint at the customer's loyalty mobile app. So that is the core idea of what we built in here. So I'll just talk a few more things, just our relationship. So I talked about our core loyalty program and that has to why we used hyperledger fabric for that and then I'm just going to, for those most of you in this audience probably already are clear about how verifiable credentials work but not everybody might know that. So I'm going to spend a few minutes just talking about the concepts of verifiable credentials. So what is a verifiable credential? It's a W3C standard that you may all be aware and verifiable credentials have been incubated in hyperledger Indian areas under the umbrella of hyperledger and the concepts are pretty straightforward. You have an issuer who has used a typical public private key photography and digital signatures and what the issuer does is whatever information, you have a set of attributes, this could be a vaccination certificate, it could be in our particular use case that we are talking about, this is the set of PII data about yourself. In either case, what you do is an issuer issues this certificate by signing this with their private key and then publishing their public key in a data registry. That's typically the only role of blockchain in here. This is hyperledger India, for example, can be any other data registry. Ideally, it's a blockchain because then it's basically functions as a distributed key management system. Some metadata such as the formats and so on could also be stored here in this data registry. But the key issue is the PII data, medical information, whatever is the subject of this particular certificate is securely held in a wallet that is held by the customer. In our case, this is a loyalty member and they are holding their own data. So we literally take their inputs. We don't store it anywhere. We simply reissue it as a credential which is stored in their wallet. Now comes the concept of a verifier. If a verifier wants to check some attribute that is useful. In our case, in loyalty, the attributes will be, like I said, your month of birth, your email address, your physical address, in case of some cases, zip code, whatever the case may be. The verifier can ask for a set of attributes or it can even be even more sophisticated. We'll have an example of that in the video that I'm going to show you. So a presentation, a verifiable presentation is made by the holder to the verifier. All that the verifier needs now is who signed this public key and if they're able to verify that in a blockchain, then that's great. In our use case, that doesn't even apply since we are the ones issuing it and we are verifying it as needed. So basically, they can check the public key, they can check this digital signature which says, yes, this was signed by the private key behind this public key. It's not been tampered with and then they can get attributes or there is concepts such as selective disclosure and zero knowledge proves. For example, if you just needed to prove that you are above 21, you don't need to reveal your date of birth. You can just reveal the fact that you are above 21. So that's one ZKB application. There could be others, for example, in the vaccine case, like I said, you could prove that you took a vaccine within the last three months and so on and so forth. So this is the three parties, the issuer, holder and verifier that are involved in verifiable credentials and that is the kind of concept that we have applied in the context of loyalty. So basically, like I said before, what we end up doing is we extend the use of verifiable credentials to store the loyalty member PII data and again, why store this data somewhere else and increase the risk? You can now give the best of both words using this technology. Now, typically when you sign up for a loyalty program, you want to be rewarded for the actions that you take, the activities that you do with the consortium of loyalty companies. So you're willing to share your activities with them so that you can earn points. So it's a little bit different than some other verifiable credential use cases in which they even try to avoid this correlation, right? In this case, you're giving them permission to be in turn to be rewarded with points but there is no need for that company to know all your details and store it in their systems. You hold it, you reveal whatever it is that you needed to reveal for which you are comfortable with, right? And if you're not comfortable giving your zip code, you can just say no and they can give you offers which are generic, right? So I think this is a new way of thinking for companies, right? It might be a little bit shocking to try and do business this way as opposed to how it's been traditionally done. If you think about all the CRM systems that I've worked in, the main thrust has been how much extra information can be collected about somebody. They want to track you every which way and the belief was that collecting all that information, they'll be able to target you better, right? But I think we have seen the pitfalls of that type of stuff. Secondly, I think the era has come that if somebody wants to use your information, first of all, they need to seek your permission and second, they need to split the proceeds of the benefits of that with you. For example, pay you with loyalty points. They can tell, hey, if you give us, if you put your zip code in your credential, we are not going to just keep it in a database but even just adding that will give you some points for that because once in a while we might seek your permission and use that particular piece of data, right? So that's kind of where we want to support the concept of true data privacy by putting this personal information into a mobile wallet and then letting the user keep control of that, right? So that is the large kind of theory in how we built this. So let me see, before I do a demo, let me see if there are some questions that are visible. Oh, sorry, I didn't check that you wanted it in presentation mode. I will try and do that in just a second. Aren't we a centralized system conceptually? Centralized in the sense of all permissioned systems, right? Our fabric network is run by a set of coalition partners or a set of companies. So are there trusted third parties in this concept? Yes, there are. This is no different than any other permissioned network. As far as the concepts of verifiable credentials, as you know, I mean, the whole thing is, the credential is held in the wallet of the customer and therefore we are really not centralizing the storage of that information. We have a reference to the customer, typically a member ID. So what happens if a customer needs to follow the GDPR concept of, hey, forget me from the system. It deletes this mobile app. We have lost the cryptographic verification. As a matter of fact, the way a person even logs into the loyalty application through the mobile app is using a verifiable credential. The credential that was issued to you with the DITCOM exchange, you are able to prove that whoever you hold this credential, there is a credential ID or a member ID in there, and you can prove that whoever is holding this phone is having that, right? So we don't need to know any further information. When that reference goes away and that person deletes it, we only have left with us a member ID which is not really attached to, we don't know who, because the member ID is attached to a certificate or a digital certificate which the person has decided to get rid of and therefore we pretty much disappear that data. So at this point, I'm going to re-share my screen so that you can actually see the quick demo of how this is put together. So hopefully you can see my screen now and I'm going to play this. Comfortable in the fluid user experience, a lot of data is involved and storing lots of personal customer information equals a lot of liability. As a business, how can you manage empowering customers to own their data while not losing the conveniences of storing information in a dedicated database? Previtch ETLP utilizes self-sovereign identities and verifiable credentials to solve this problem. Here's an example. A customer, Kevin, has just downloaded a loyalty program app and is ready to register. Though this may look like your typical registration process, in the background, a digital credential with this information is stored in Kevin's personal mobile wallet. Kevin's information is securely stored on his personal device, not in a database. Now to log in, Kevin selects log in with verifiable credentials. With this feature, Kevin does not need to memorize a username or password. The loyalty app instead requests to check he is carrying the appropriate account credential. He simply scans his fingerprint to authorize the app access and is redirected to the loyalty app home page. Kevin wants to order a beer flight from his favorite brewery when he is ready to redeem the app asks permission to confirm he is of legal drinking age. With a quick scan of his fingerprint, the app checks Kevin as above 21 and approves the redemption request. In this way, digital credentials allow Kevin to take control over his information while maintaining the flow of a smooth customer experience Learn more at pavichi.com All right. So that is the presentation, which kind of illustrates the concepts that we just talked about and it shows how you can construct a loyalty application. Now, of course, there are some questions that you might have. For example, how did it check the age? It's a self-declared date of birth that you do when you sign up to a loyalty program. Many of them want to make sure that you are at least above 21 but you also realize with verifiable credentials that you can hold multiple credentials. People are talking about doing even driver's licenses in a digital wallet. When that happens, when you have multiple credentials in a wallet, it's possible to do what's called a composite presentation. For example, you can present your proof that you're above 21 from your driver's license and from your personal information digital credential you can pull some other data. So these possibilities are certainly there. So let us see. And I think Trevor, you said, are you thinking that because the same entity is both the issuer and verifier? Yeah, in this particular case, we just want to use the verifiable credential concept so that we don't hold that information. In a typical system, the issuers are different than verifiers. In our case, we are using it in a slightly different way. Thank you, Jim. Let us see if there are questions on this one. Is the loyalty application and the wallet application the same application or are they two different apps? They are two different apps. The wallet application is the mobile piece and the apps, too, think about it as talking to an API layer which is the rest of the loyalty application. In itself, so the way we architect is, of course, we have Hyperledger fabric in the back. On top of it is our chain code and then the API layer. And on top of the API layer, we have an administrative console for administrative purposes. We have a mobile app which can talk to it. So there is a separation of concerns about the API layer, so to speak, and the mobile app. The mobile app is a wallet. So that's an interesting question which is, you know, this whole paradigm of using wallets is going to get stronger and stronger. And what happens is, as time goes by, people would want to have both the ability to store verifiable credentials. It could be store cryptocurrencies and so on and so forth. So the wallet usage needs to get way better, right? And I think over time it will evolve because today wallets can be a little cumbersome, how to restore them, you know, if you lose stuff and so on and so forth. So I think that's an area of research that is very strong. I saw some great new advances using things like threshold signatures which will make the application of wallets much easier. Without changing traditional customer onboarding process in lending world. Akshay, could you integrate this in a traditional lender customer? You could. Again, depending on, I think in the loyalty use case, the bottom line is that information we feel is secure enough in their wallets. Like I said, the wallet process needs to get a lot more stronger because in a lending world, there may be multiple occasions for them to get your information, right? So it becomes really difficult if you have to have the person online to authorize every interaction. I think the world is going to move to a better place, Akshay, where there may be ability to have secure cloud-based wallets, agents which you can deputize that can work with those wallets. And like I said, with concepts like threshold signatures where you have multiple parties will have to agree instead of this single private key being the problem, right? You lose the private key, you lose everything type of a situation. Then those improve, I think all those applications can come before. Any other questions that you'd like to post in the Q&A chat? If nothing else, then we will close a little early, give you guys some of your time back. Enjoy the rest of the presentations. Again, I'll post here in chat where you can reach me if you have further questions. I'll be happy to be in touch or hit me up in LinkedIn and happy to answer any questions. Thank you, folks. I missed some questions. Bogdan, can you point me? Let's see. In the Q&A section? Okay. Okay. Okay. Sorry. Okay. There is this. According to our experience, our company is interested in allowing customers to exchange tokens. A blockchain could be useful for this person. Yeah. The concept of exchanging tokens for some other tokens, that is multiple point types. As a matter of fact, we have designed that within our application and there is interest. We are pursuing some opportunities right now in Asia where they not only want a coalition loyalty program, but they also want to be able to exchange points with other popular programs. For example, Grab is a very popular Uber-like network and they have their own loyalty program and there are consortium of companies which want to have their own loyalty points but be able to exchange it. That is coming for sure. But in loyalty, so far, the concepts of tokens is a little bit different than an ICO or regular crypto token. Tokens are covered. Basically what happens is when a company issues tokens, they differ the revenue. They differ the revenue for that amount. So let's say they give you a dollar worth of points for $10 worth of purchase that you made. Basically, they differ that $1 of revenue until you're reading the points. So all points are actually backed by the deferred revenue of that company. There is a concept of breakage and so on and so forth by which it's reconciled. So the accounting behind it is a little bit different but that could be a way in which crypto tokens can also be acting as loyalty points. I think that age is coming. Which wallet app are you using and where can I find the APS to connect my app to it? The wallet app that we are is custom built, right? It's just part of our, as a matter of fact, for verifiable credentials, we use Evernom as the, you know, Evernom agents and the Evernom SDK. And so we pretty much use the, if you are familiar with connect.me, that will be the app that, you know, that we kind of model ours on. So that's what we are using right now. Again, wallets are going to be standardized at some point, I think, which I believe will happen sooner than later. Are you running on a pre-existing network? So these are, you know, individual networks that we are standing up for customers based on their requirement, you know, a consortium of companies get together. We stand up fabric. We can do it in AWS or at the cloud, you know, pretty much anywhere that the customer wants. Our pilot, we actually did it through a private network that the automotive OEM wanted. Okay, I think that answers all the questions. Jim, is that the presentation mode? Sorry, I was trying to figure out how to do that. All right, if there are no other, yeah, okay, there is one more from Paul. How did you accomplish such a smooth integration between wallet and loyalty app? Basically, like I said, you know, because we kind of know both sides, right? So we know the communication back and forth, but the most important thing to really understand is, you know, we kind of know what is in the credential simply because we defined it, but could we use just any public wallet that somebody else writes? It can be done. The only problem is, like you said, the integration between the loyalty application pieces and what needs to be retrieved from the wallet could be, you know, a little, it's just smoothed by the fact that it is in a single application. That's all. That's why we prefer to use the, like I said, they have an MSDK and then kind of stick it with our, you know, our loyalty app. Okay, folks, I think our time is up. Thank you so much for your attention. Like I said, please feel free to contact me and we will see you somewhere else. I'm sure in another presentation. Enjoy the rest of the conference. Thanks.