 Doing half an hour presentation, half an hour Q&A. Yep, I mean, but you can go 45. I mean, if you want to go longer in the press, whatever you feel best, but we got a full hour. So whatever works for everyone. More time for Q&A, the better. And if the discussion goes on, you have the Zoom room for actually more than half if you need it. And you are now live on YouTube. I'm dropping the YouTube stream link on the Zoom chat because there's also a chat on there. So if people want to keep an eye there for questions. Alrighty. Well, if we're ready to get started, let's do it. So hi, everyone. Welcome to today's Washington DC Hyperledger Meetup Session. I'm Jeff Tenenbaum. And along with Daniel Yem, we host these quarterly sessions. And today we are super excited because we have two fantastic speakers and we're covering a topic which has gotten a great deal of press, which is digital health pass. So you may have heard about this technology on the web or on CNN. So today we'll jump into how it's being used and how this technology works. Our speakers today are both IBMers, Anthony Day, who is a blockchain transformation leader out of Ireland. Yes, waving at us. I highly recommend you check out his LinkedIn posts if you get a chance or his podcasts. Blockchain won't save the world. And his latest is a roast on non-fungible tokens. And if you wanna get into, if you were an NFT, what would you be? This is the podcast for you. Now, trust me, you wanna check it out. And we also have with us Dr. Francisco or Paco Cabera who serves as the director of innovation at IBM Watson Health. He leads the development of blockchain technology and solutions for healthcare and life sciences at IBM. So with that being said, let's jump right into it. Anthony, Paco, please go ahead. And I am happy to share the screens or the slide. Control the slide, I guess. Yeah, thanks, Jeff. I appreciate it. Hello, everybody. Happy Friday. We made it. It's nearly the weekend. Thank you so much for spending the next hour or half an hour, whatever you can spare with us. It's been a long week and this is a particularly emotive topic for everybody. Paco and I have been working in this particular space, particularly around COVID credentials or health credentials for the last 12 months or so. As a double team, talking to governments, airlines, travel organizations, all sorts all over the world. And we've covered everything across the spectrum from elation to pure hatred in terms of this as a particular topic or as a particular technology capability. So we're gonna try and share as much of that with you today as we can to let you make an objective call for yourselves in terms of what's the current state of play? What are the issues? What are the technology solutions? What's being done? What's happening in the real world today? And what does that mean in terms of use of blockchain technology in terms of how this fits with other technology capabilities, other digital, non-digital journeys. And hopefully after an hour with us, you'll feel a little bit more gend up on the topic than you were when you started. If you weren't, my apologies, but grab a beer, grab a cup of coffee, whatever gets you going on a Friday afternoon. And yeah, thank you very much for hosting us. This is my first ever Hyperledger Meetup to present. So please be gentle in the Q and A and thank you again, guys, for joining us today. So as I mentioned, this is a particularly emotive domain. Number of us in a number of jurisdictions, countries, locations around the world have been locked down, have been kept from our colleagues, our loved ones, from travel, from sport, from entertainment, from whatever it might be that we were doing 18 months ago. And as a result, life has changed. We've seen some huge positives in that time. I think you look at the self-sovereign identity domain, the digital identity domain, the awareness of the possibilities, the awareness of the capabilities and the awareness of the role of blockchain in this particular space over the last 12, 18 months has accelerated more than I thought any of us would have ever thought possible. So in terms of awareness, in terms of understanding, in terms of this space getting fair interest and respect, I think that's been a huge positive. Looking at the public-private collaborations between governments and technology organizations over the last 12 to 18 months has also been a real positive. Things have been developed, put into practice, really fast. Policy doesn't necessarily move quite as fast as technology, as many of us know, but we've seen a lot of really good work, and I think that will endure above and beyond the pandemic and what comes next. I think what we've also seen is a huge amount of collaboration between peers, competitors, collaborators, in terms of standard development, in terms of technology and harmonization and interoperability, which all of us working in the blockchain space knew was important before and we were very open to before this happened, but at the same time, you've seen other organizations who've come out who are relatively new to the technology domain or companies looking to pivot into the identity space have quickly realized actually it's about working together and that there's not gonna be any one health pass to rule them all. And to be clear, that's IBM's view of the world also. We're not trying to say IBM Digital Health Pass is the only way of deploying digital health credentials or verifiable credentials in the world. What we are saying is we know a thing or two about the architecture and how we make it work, that we're deploying it for governments, for airlines, for organizations around the world, that there are going to be other platforms and other protocols out there that we need to work with. We're gonna see a smattering of different government solutions, a smattering of different private sector solutions. We're just getting round to the idea of vaccination certificates. Anybody in New York State will have seen Excelsior Pass and the work that the guys are doing there. The IBM is powering at this point in time. There will be others coming soon, don't worry. But you'll have been seeing that firsthand and that's primarily around vaccination. From a policy perspective, that can't be the end of the solution. What we have to have in this space is accessibility, so digital, non-digital journeys and that any solution is equitable in terms of those people who don't have smartphones, who don't or aren't as digitally literate that we have the ability for people who haven't been vaccinated or can't be vaccinated or won't be vaccinated to also be able to demonstrate a credential that allows them to be deemed as safe in the eyes of whoever is verifying. And that's where the contentious part of this comes because that comes down to policy. That comes down oftentimes to government's decisions on where should credentialization happen. Our role is to help provide the technology that is safe, that is secure, that is scalable, that is accessible so that we can put that into practice quickly and safely because frankly, the enemy of progress in this space right now is paper. It's people carrying paper documents with QR codes around where you've got 90% of staff and airports right now serving 30% of the passengers. You suddenly bring another 20 or 30% in addition to that all carrying the same amount of paper. The system breaks real quick and you've got queues for four, five, six hours at airports or ferry terminals or wherever it is you happen to be credentialing people and that's gonna be a problem. Anybody standing around in large queues of people waiting to find out if they're safe or not in a pandemic, it's probably not a great situation to have to end up in. So this is what we're trying to avoid is the digitization, the automation, the trust around credentials where it's appropriate for them to be used. And also let's be clear, none of us really want to be credentializing ourselves to go into the supermarket, to go into coffee shops. That is not the vision that I think anybody wants in this space. There are some policy makers who believe that that's necessary, but we hope that's not the case in a broad spectrum. We don't wanna see 1984. We don't really wanna see this technology being pervasive beyond the time that it's necessary. So this is not some sort of large draconian play for gathering lots of people's data. It really just is about verification with the policy we have at this point in time. And we believe that with digital health pass and the implementations that we've done, we've done a decent job with the governments and the clients that we're working with to make that equitable, accessible, safe, secure and scalable. So let's get into the stuff. I'm great at doing long intros without showing you any slides so people have to stare at my face for a long time which I realize is probably boring for you. So let's look at some pictures and visualize this. I'm gonna cover a little bit on the context and Paco's gonna do a deep dive on the architecture and what sits behind digital health pass. And I know all the hyperledger folks out there are dying to get into the nuts and bolts and the weeds of this. So I promise we'll leave as much time as we can for people to come and come with questions. And if we don't cover it all today, please come find us afterwards because this is a topic we're particularly passionate about and very happy to help share knowledge on because the more knowledge, the more awareness people have of this space and the issues, the more we're able to be objective and try and put clear and calm messaging out as opposed to hysteria, anger and hate, which no one wants on a Friday. That's my opening salvo. On to the next slide, please, Jeff. So every health business, sorry, every business is now a health business. This is the slightly slogany conclusion to we have now got one of the largest digital transformation challenges of our time, which is the ability to issue and verify credentials for health on a global basis. That's where we're at. That's the interesting realization of this is that it crosses borders, it crosses industries, it crosses state lines, it crosses modes of transportation. It covers everything. Employers have been trying to figure out how do I get my staff back to work safely so I can continue operations? How can I manage an ongoing testing program for people who can't socially distance in a way that doesn't involve carrying hundreds of pieces of paper around? Particularly for example, look at the oil and gas industry where you've got people working on rigs for months or weeks at a time, carrying lots and lots of paper documents out to a heliport to go and fly, anyone who stood near a helicopter carrying bags of paper, not a good idea, generally speaking. But above and beyond that, there's a bit here about automation, about the efficiency of workflows and those validations where the short answer is get a piece of paper because we can figure that bit out first. That really isn't the answer long term or it isn't particularly scalable or it also doesn't allow you to get insight into where are we seeing outbreaks? Where are we seeing problems? Where are systems breaking or where are we going to have to quarantine or manage certain facilities at certain points of time? There is a data element to all of this. Next slide, please, Jeff. The next slide has some numbers and this one is relatively controversial because for those who are pro-vax, this kind of makes a lot of sense, right? Saying a number of employers are looking at actively incentivizing their staff to get vaccinated. Those people who are undecided or can't get vaccinated will look at that number and say, not sure how I feel about that. I, for one, probably won't be redeeming the free Dunkin' Donut you get every week, not least of which because of my waistline if I get vaccinated, but living in Ireland, we don't have Dunkin' Donuts here either so it's not really available to me. But this is the real statements from real employees and real employers at this point in time saying, we need to demonstrate that our staff are safe and we are prepared to look at incentive models to make that happen, which I think is a really interesting sign of our times. Next slide, please, Jeff. And what's the business case or what's the rationale? I think from a government and a public safety perspective, I think we're all fairly aware of the issues, but when we talk about enterprise and a lot of the organizations we work with are enterprises, the cost or the trade-off that they're looking at in this particular space around credentialing is, outbreaks, the costs of shutdowns, market positioning and reputation, if you're found to have had an outbreak or if you can demonstrate that your staff have been tested or are relatively speaking safe, you can use that as a way to say, we have a five-star rating. You're safe with us, customers, you can come back. Don't worry. Business travel is an interesting one, right? Particularly for organizations to have outbound sales or engineering teams. This is a critical requirement. What you don't want is your staff to be quarantined in locations where they have to spend four or five days in some sort of airport kennel before they're allowed to actually go out and deliver value to your organization. So strategically sourcing credentials, access to testing is actually a differentiator now, which again, we wouldn't have thought 18 months ago. Employee productivity and retention, the ability for employees to feel safe. PWC in the UK about 12 months ago came out and said, we're going to actually test our staff or we're gonna actively offer testing proactively to our staff, not as a means of differentiation but as a means of helping with their general feeling of wellbeing to help manage anxiety. This was something that they said, we want our staff to feel safe if they've got to come back to offices or they've got to go and meet clients in a way that it cannot be avoided because they're working on mission critical sites. Retention and employee safety is a big part of it. Obviously risk reduction and then the trade-off of revenue generation revenue protection. If you're not able to operate your businesses, your facilities, your manufacturing sites, your logistics in the same way that you could do previously, you may lose business. And then you're looking at the trade-off of proactive testing and the cost of a test, which can be anything between 10, 15 and $150 of how often do I test? How many staff do I test? How much revenue am I losing? And how does that equation stack up? And for the number of staff that I have, am I doing this for five or 50,000? And as a result then the role of paper versus digital becomes much, much more clear. So these are some of the challenges at least purely from an enterprise perspective that myself and Paco and others have been talking through over the last 12 months and a number of organizations are on the fence. Many organizations have said we'll work from home forever. Others have said those who are already out there, you saw Amazon very, very early setting up their own testing capability, setting up their own labs to test our own staff because they saw that as a critical requirement. So every business is a healthcare business or at least every business is thinking about healthcare in a slightly different way than they were 18 months ago. Next slide, please, Jeff. So the trifecta, this is what it all comes down to. It's gonna be the individual, the citizen, the issuer of credentials and the verifier of credentials. So many of you will probably already be familiar with this. If you've seen any of the work around self-sovereign identity or trust over IP, if you've been reading up on these things, you can probably switch off and have a snooze or do your shopping list for the next two or three minutes while they explain this because this should already be second nature to you. But for most people who think about the concept of passports, they're immediately thinking, well, obviously there's a bunch of PII that's going on to a blockchain. And that's really not the case. What we're trying to do is we're trying to keep the contract between the individual and the issue of the healthcare organization that you agree to be tested, that you agree to be vaccinated, that you agree to have a procedure of some sort. That consent is given. The data held by the issuer, the healthcare organization remains there and is held there and is kept there and protected there under GDPR, HIPAA, whatever regulation is required, that doesn't change. What we're looking to do is enable that issuer to generate a verifiable credential that can be held by the individual and shared with verifiers. Verifiers being airlines, schools, academia, whether that be healthcare organizations themselves, the employers, retail locations, if we go to that extent, hopefully not ice cream vendors. I don't know how that ice cream made it into the bottom right hand there, but I really hope it doesn't get that far. This is what it's all about. And the dotted lines in between here is what Paco's going to explain in more detail later is how it works underneath. What it comes down to primarily is about standards. It comes about interoperability. It comes about allowing individuals to share those credentials in whatever way possible. Most people recognize this as a QR code, right? I show a QR code on a phone, somebody else scans it and in I go or that it gets verified. The verifier returns green red or in some cases the verifier sees a credential with my name and another piece of data that I have to verify. I then have to show my driver's license, my passport, whatever it might be. And on that point, I'm then able to go in. And there's an important distinction here between a credential and an identity. And at a vanilla level, IBM Digital Health Pass is about issuing certificates, credentials, not about digital identity because that's a slightly different kettle of fish. And for most cases, governments and regulators are not looking to issue digital identities alongside health credentials at this point in time because the concept of government digital ID is particularly sensitive if health credentials were not already so. So we're talking primarily about an unanchored credential at this point, but we're very familiar with the space of tethering that to a digital identity and then allowing that experience to be fully digital. Moving on, please, Jeff. There's a video here, but in the interest of time, I think I'm gonna skip it because I'm pretty sure you guys can imagine the idea of something being on a phone and it being scanned somewhere and life goes on. So I'm gonna skip to the next slide so we can spend more time on Q and A if that's okay. You are. Keep going. It looks like probably two things. It looks like an app for you. Now that app is typically not branded IBM. It's branded New York State Excelsior Pass. It's branded German Ministry of Health COVID Pass. It's branded a number of other different things and the verify capability that may or may not be in an app. It may be part of an online journey. It might be part of a token journey. It might be a number of different things and depending on the industry, the setting, we see a number of different patterns for how verification happens, but it's probably those two services at a first look. Next slide, please, Jeff. Here's what it might look like on your phone. Number one, you've got the wallet. Within that wallet, you can look at your credentials, you can share, you can scan to be able to get a credential from a portal, from a piece of paper, when you're in the doctor's surgery and after having done that and downloaded the credential to your phone, you get number two, which is sure enough, a COVID test result type credential with a QR code on it with the relevant metadata that says this is when it was issued. This was the type of test. This was the result. All of the information that you as an individual might want to see and know in case you get asked and then typically a button at the bottom, which says share. On the right-hand side, you're looking at a verification side of the screen which says it hasn't expired, it's valid, the valid signature, so this is an entity, an issuer that we recognize, that could be the government, that could be a test provider, whoever on the network is trusted and this is an important distinction between where we're at at the moment. A lot of the government solutions are a first up looking at vaccination certificates from public health databases but what we need to be driving towards for equitability is vaccines, tests, proof of recovery that will also eventually end up including the private sector. And so the network and the decentralized IDs and the participants on the network will need to expand beyond just individual governments, one issuer per country. So that's the journey we're on right now. And you'll see in there, there should be absolutely minimum PII, if any at all, depending on how you configure it. If the identity is already proven alongside the credential, you won't even see the name of date of birth. In some cases, you'll scan that and you'll say, you need to verify that this is Antony Day date of birth X, Y, Z. And again, depends on the journey but that's kind of what you see, quite simple but the magic is what happens underneath. Next slide please. Here's an example of what it looks like in New York colors. So the Excelsior digital health pass was launched in March. We had something like half a million users within the first three weeks, it's probably close to a million now, if not more. And it is within its own dedicated app. There's also a supporting portal. And on the portal you go through a number of challenge questions to enter information that should only be known by you and after which you then get a QR code which you can either print or download to the app. This is important because again, we're not tethering a digital identity here. We don't have a New York state national ID or something like in the UK, we have the national health service which has its own digital ID solution that you could tether to the credential if you want to. But in this case, we believe that authentication could be sufficient by going through the portal. That's for accessibility, that's for speed, that's for trust. Also a lot for the user experience and having been through a number of these journeys, that's typically the pattern that is being deployed. It's not the only one, there are many different options and there is a trade-off in taking that particular pattern but that's if you're a resident of New York state, what you'll be experiencing today. Next page please. And as I said, there is going to be a patchwork of a number of different solutions that you're going to see and this is where the integration challenge comes. So if you're an airline that's operating in a number of different countries, you're likely to be receiving credentials from national governments, from local test providers if you're in the US, from Clear, from IBM Digital Health Pass, from New York state, from a number of different states who may all be having slightly different directions. If you're coming back, you might have received a test in that particular country that might be downloaded to a pharmacy's wallet or private sector solution of some sort. You might be working and holding IARTA's travel pass or an NFL specific travel pass where they have their own testing partners. We believe and we hope that a lot of the technology and the standards that sit underneath that are going to be common. But as a citizen, it's entirely possible you're going to be holding two, three, four, maybe even more of these types of wallets depending on where you get tested or vaccinated and depending on what the protocols look like going forward. So this is the mishmash of what's going on. And as IBM, we're participating in a number of these global standards groups, WHO, VCI, the Good Health Pass Initiative, which is where most of the private sector wallets are coming together to make sure we're aligning on standards is a lot of good work going on. It's not finished, it's not done, even in the EU, their standards for the EU digital green certificate is still, I would say, hardening. It's gone through a little bit of flux and a little bit of testing over the last few weeks, but it has been largely developed and rolled out in a couple of months, which for the EU, pretty impressive, generally speaking. Next slide, Jeff. I'm going to skip this one because we're coming close to half-past and I really didn't want to spend this much time talking. So keep going to the next one. I want to get straight to Paco's slides if we can. Here we go. Right. So that's it from me. I hope that's some useful context. Paco's going to take you through the architecture, the underlying components, where the hyperledger bit fits in, and then we'll try and get to as many questions as we can fit in, because I know on this particular topic, loads of people want to know more. So Paco, over to you. All right. Thank you, Anthony. Great introduction, overview. I'm going to go briefly over the structural architecture of the system. I'll talk a little bit about the workflows and end up with a discussion of the design principles behind our solution. So what you see here is a high-level architecture view of the solution. We build on hyperledger fabric, as you all know. That's what we're here. Well, what do we use blockchain for in this case? So we don't store any type of PII or even hashes of PII in our blockchain, right? The blockchain is just there to create trust between the end-to-end workflows, between issuers, holders, verifiers. So blockchain holds information about issuers, so the verifiers can look them up to a query against the ledger and find the actual trusted information about these issuers. It's somebody that we know about, it's been onboard, then this is the data, we can use it for verification, right? So this is a very important approach, differentiation that we have. I mean, many of these solutions can keep the miracle hash in the ledger, the root in the ledger, hashes of different types. We've been very, very strict about keeping any kind of PII, hash PII, which as you know, for GDPR is PII on the ledger, right? But we still leverage this ability to create trust end-to-end, right? So what do we do? We register issuers on the ledger, we keep the information that is needed for verification. This is public information about who they are, their privacy policies, business information, plus what type of credentials they issue. They'll stand behind public keys so you can take the public key and verify the details signature, right? We also keep revocation registry. Let's say a batch of test kits was proved to be defective. So a test lab that had been issued credentials for a bunch of people may come in addition to notify them, they'll revoke those credentials. So these people, which may be potentially infected, don't go to a public place, right? That's also kept in the ledger. No PII is completely opaque credential identifiers. We don't even keep a log of what credentials were issued. We don't actually help you back anything up. If you get your credential from us and you lose it, you're out of luck. We're not gonna help you, why? Because we don't want your PII. So you need to back it up, back your phone, copy the piece of paper where you printed your QR code or go back to the issuer and request it again, which is how it works in New York, right? Now, the architecture otherwise is what you would expect. We have a cloud hosted, we run in the IBM cloud. We have a microservices layer and we expose a set of APIs. I'll talk about what they are in a bit more detail later but essentially to allow issuers to issue credentials, verify us to verify and support some of the workflows that you will see end to end. Anthony Shoe, we have two apps in the app store. You can download them. They were the base for the New York State app that you saw there. So we see our clients wanted to rebrand or build on top of our apps. There's an app for the holder, an app for the verifier. We provide also a mobile SDK so you can incorporate this capability into your own app. So many of our clients don't want to sort of disrupt the existing digital experience of their own customers. For example, airlines, they have an app. They invested heavily in this very, very slick digital experience that many of them have. They don't want to ask for another app. So they look into embed the wallet capabilities into the app and then embed the verification capabilities into the existing workforce, right? So this is the end to end view. It's very flexible. So let's go to the next slide and I'll show you a little bit how we support different type of workflows. So what you see here at the bottom is a schematic of the platform. And so we're a SaaS platform, right? So you could just consume our APIs. We can allow for certain on-prem deployments. We see some of our clients like to issue their own clientele from their data centers, some governments, some health systems for many reasons, right? Security, political reasons, policy reasons. We support that as well. You take the code, we'll help you deploy it, you run it. What do we do? We register you in the ledger. So anybody in the world can look you up and verify your credentials, right? Doesn't matter where they get issued. So issuers that you see here in the top left can call our issuer API or do their own issuance. They hand the credentials to their holders, to their users. And we've seen these different ways this can happen. New York State is a typical example set up a portal. You go, you authenticate, they ask you a few questions and make sure it's you pull your vaccination record, call our issuer API and then display a QR code on the portal. You can scan it for your app, goes into your app, you can print it, get us a PDF, or you can directly download into your app, right? Then you're having your Excelsior app. We can also help you if some of our issuer partners use what we call this PO Box capability is a temporary secure storage. So when the issue happens, we put the credential in the PO Box and the user can download from their app, right? Then it's deleted, right? Now the user will then share with a verifier. Standard, most immediate ways, display QR code gets scanned by the verifier app, right? That's in-person, that works, it's great. What does the verifier do? They read the credential and then they extract the centralized identifier that we use to identify each issuer and the performer lookup against the ledger for that issuer. If the issuer is there, we retrieve public keys, schemas, basic piece of information and with that, verifier goes on and checks the signature, checks that the credential has not expired and they can do another call to check if the credential has been revoked or is registered in the revocation registry, right? Now that same process can happen on the backend, right? So we usually hear this data exchange service, we provide a facility from the app, upload to temporary storage on our cloud and then the verifier can pull the data, the credential from that storage, verify on their own. And let's say for example, when they check that this passenger has the right testing credentials in the right time, update the travel record and issue a boarding pass. That's what we've seen again with airlines. So both in-person and online sharing is enabled. And as I said, you look here, data is of course there's with the issuers who has their source data. Otherwise it may be processed by us, right? If they use our issue API, we don't store anything. As I said, data is kept at the edge, right? Goes from the issuer to the holder to the verifier. Okay, we can go to the next slide. These are just some of the design principles we've been focusing on. You see this is very focused on EU requirements and part of this, as you know, Europe has a very strong focus on privacy and security. Our system was actually designed by our IBM research team in Switzerland, which is one of the research lab we have around the world. This one focuses among all the things in privacy and security was a very, very strong team. They have been building solutions. I mean, actually they were involved in many of the different hyper-ledger projects in the included a lot of trustworthy IP discussions. But they basically designed the system and it's actually designed with privacy and individual control of the data at the center of it, right? So data, as you saw, never gets out of control of the individual. We have many clients asking, well, if you issue the credential, can you send us the data directly? As there's no, and we say no, but it's a principle of the side. This is very sensitive data. We want all our clients and users to know they're always, they're really always in control, right? And we enable this peer-to-peer operation. We enable disconnected verification as well. So you can, you don't need to have a connection with the platform to create, to verify that credential is valid. So data, as I said, stays at the edge. No data in the backend, no data, no PII data in the trust layer, right? Just business information, right? Now, some requirements are, of course, interpretability. I don't even mention that. This is a very, let's say, a complex landscape. There are many, many initiatives. We, of course, expect there's going to be a lot of convergence around the main standard, the open standards initiatives. We see that what Lingers Foundation is doing, how good help pass is building on the open standards, trust software IP. We have a lot of the industry there. We are very consistent with that one. We build on double three C standard, prefrontal credentials, the centralized identity. So we think that's going to capture a lot of the thrust in the market. On the other hand, we're aware that there are many players here and we're not going to converge anytime soon or if ever, right? So our approach is one, build an open standard, support, participate, but at the same time, make sure we support our clients, all the major types of credentials and formats out there. We call that sometimes the verification hub approach, it's not going to be a convergence anytime soon. Airline passenger comes up with a credential from that may not be built on the same standards that most people are building, but they say in a particular region has a particular acceptance. We'll know how to, we're actually working already with some partners to be able to scan those, verify them and provide the provenance of what, where this credential comes from, who has signed it. In the end, if you think about this, people want the organizations, want somebody to solve the problem. They don't want to deal with standards, different technologies, these are what we're there for, right? So that's our approach. In regards to what we're doing, extremely focused on privacy, opens, legal requirements, et cetera. We have a commitment to open source our system. We're starting this process already. Why? Of course, open source is very good for many reasons. Helps the community get engaged, leverage the developer community, but also it's transparency. In this case, you don't have to, you won't have to take my word for it. You'll be able to see what we do with your data or how data flows through the system. And we think the best way to achieve acceptance is full transparency. And that's why we're in the process of open sourcing the full platform and the apps, right? I think another big part of this, Paco, was the scalability requirement is that in a number of countries, you're looking at multiple hundreds of millions of citizens holding and managing transactions on a platform where those people looking to implement, whether it be governments or state authorities or whoever it might be will say, show me that the platform or the underlying capability here has scaled to hundreds of millions or billions of transactions yet. So with Hyperledger Fabric, we know that that's the case. We know that there are a number of other design patterns that are possible for this, but that for IT security or government IT security specifically, other design patterns will immediately be ruled out because they have not passed the, we have approved a number of transactions or scalability hurdle, which is frustrating, particularly for those involved in the likes of Trust Over IP or Indian Aries where I can see a bunch of questions coming down in the comments of why, how does zero knowledge proofs fit here? How does India fit here? How does Aries fit here? We'll go through that as much as we can. Part of this is we've got to try and find something that's suitable for the environment in which it's going to be deployed. And that often means compromise. It always means compromise. Yeah, yeah, I think that's an excellent point is for the environment and also for the timeframe, right? Because we realize, so in the middle of late last spring that something was needed quickly. There's a lot of very relevant technology coming on board, I mean, this work and all of these technologies. Unfortunately, not everything was that we like to use was ready for prime time to put into production and we started running pilots with large employers in the late summer, right? So in a sense, you make a compromise. Say you want technology that's gonna line up with the right standards, the right direction, but is ready for our clients. Scales, it's secure, it's production ready. So that's a little bit the constraint you work with, but this is what clients or customers are looking for, right, solutions for problems today and make sure as we move forward, we are in the right, we're moving in the right direction, right? So I think we mentioned the fact that we've focused on making sure that there were low tech options available. This is a big focus on almost any government. It's also one of the main threats in the good health pass set of specs. So we of course support this in New York State, people are printing their passes and you just print the QR code works everywhere, right? Okay, next slide. I think we talk about this. I mean, just mentioned that we're basically engaging with almost every standard and industry initiative in this space. Why? Because again, we believe that it only works if it works globally across countries, across technologies, right? The more we can simplify and get agreement on serialization, schemas, verification models, trust network, which is something that is often overlooked. How do I know, not just that this credential is valid, it's signed by an issue, but who knows who that issue is, right? So there's a level of provenance here, which also needs to be taken into account, right? So we're implementing standards that are well established and we're actively participating in all this that you see here. So we see this as a journey, right? We just, I think we have a solution. We know that it's already been used in production solve the problem, but we're gonna keep working so that we have the broad level of acceptance and interpretability that our clients needs. So I think with that, this is my last slide. I know we have a conclusion slide. Go to questions right away. Great, thank you so much. Yeah, that was excellent. Thank you. So looks like we've got a bunch of questions in chat. So we have plenty of time. I guess, I don't know if we wanna start at the top. Can you display that last slide while we're doing questions, please? Sure, absolutely. Let me go back to it. How's that? Can everyone see that slide? Yes, thank you. You're very welcome. So I don't know if the problem that I have right now is if I wanna look at the chat while I look at the slide, let me see, maybe I can move this into my other screen. I can moderate, Jeff, if you want to. Let me moderate. I can see all of the questions up here. So let me moderate if you're ready. No, no worries. Yeah, if you wanna get started, please, by all means. Otherwise, I can, I have it now so I can start going through them or if people wanna ask and just take themselves off mute, we can do that as well. But maybe we'll start with some of the questions we have because it looks like there's plenty in there. There's a few. Why don't we start with the super chats and the ones of people coming in from different blockchain associations around the country, around the world. For real, let's talk with the one that actually, everybody wants to probably talk about PAKA, which is why fabric for DID and not Indian Aries. Let's go with that one, shall we? So it's interesting. So we, as you probably know, we've been involved and we're still involved in Indian Aries as a company, right? We're part of a regional group launching this project with streaming involvement trust over IP. We did an evaluation in, I think it was April last year, right? And we realized that, well, some of the components, for example, in India, it was very mature. All there's, didn't have the scalability properties that we're gonna need, right? I think Aries is a great framework from a scalability maturity point of view we're not convinced we could build on that. So what we decided to do working with our research team is let's say we build on fabric, which is a very, very, as you know, extremely mature, extremely strong foundation. We build essentially a slim layer of smart contracts and we have an offering that builds essentially a trust over IP layer one and a set of specs and can solve this problem and can grow to be fully compatible with Aries and Indy. In a set, we like to look at this as potentially another implementation of the similar and interpretable set of standards, right? So we're kind of a little bit agnostic. We're not trying to say one is better than another. We just needed something that worked for our clients and would scale with production already. All right, thanks, Paco. Let's jump to the next one about verification offline. So offline verification, we can talk about how that works. Yeah, so what we allow, and it's interesting, this is how the near app works, right? So I think Anthony mentioned that. So near state offers these verification app, which is essentially free. Anybody in the state actually anybody anywhere can download. We'll verify the near state pass, the accessible pass anywhere for free. What it does is that it caches the keys, right? So when you do a verification lookup against the ledger, what it returns, I mentioned before, is basically a schemas on the public keys you need to verify the credential. So if you catch those keys, you can verify at the edge without having to go back to the platform, right? In many cases, we see clients are working with a set of labs. You can catch those in, right? So you can pre-cache or allow simply the caching mechanism to use in different algorithms, right? So that's essentially how it works. And there's another question here about revocation. And this is one that the EU has, is still struggling with a little bit from a policy perspective. But can you talk about how we are to detect it in revocation? Yeah, so what we're doing in revocation is that, so by the way, revocation doesn't work in disconnected mode, right? It's a central registry we maintain in the ledger. So what the issuer can do is if they decide find out a certain number of the credential the issued are not correct to be revoked, they'll essentially register the dates of those credentials into this registry. So then when you look them up, you can find which credentials are revoked. So it's a very simple model, it's on the ledger. So it's secure, it's trusted, but they pick it's potentially a large set of data. So unless you focus in situations where you say you focus on one issuer, you may be able to cache and do some caching mechanisms on the device. And we're looking into that. At this point, we don't have it enabled as a disconnected mode. Thanks, Bakko. Question from Maria here, could the same code be used for a completely different industry but with the same concept? So essentially, is this a design pattern that can be used with verifiable credentials outside of healthcare or in the case of university qualifications or other verifiable credentials? Except this, it is, right? It's the same model, it's the same, a double-thrusty, very powerful credential model. And, you know, our clients are asking about that, you know, once they go into this type of credential, why not all our credentials? We also built it in a way that we, the way we anchor identity is so flexible. So you anchor in digital identity if it's available, you anchor in physical IDs. So they give you a lot of flexibility to capture all kinds of use cases. And the answer is yes, we're very focused on healthcare, we're focused on health, focused on healthcare, but it's the same model that you could use for learning credentials or others. Okay, this is, somebody has set us up with the shameless plug question, which I feel guilty in answering, but I'm going to answer it anyway. Where do we find more stuff about this? I literally just Google IBM Digital Health Pass. You're going to find out various different bits of information around how it works. There's a great page on Watson Health page about how does it work, what are the different layers, what are the different components, a nice glossary in there. So, Cain, if you want to check that out. Also, you can Google New York State, Excelsior Pass, plenty of press coverage in there. Really, really interesting article from Crystal Weber. She was in Fast Company, I think it was Fast Company, explaining the design principles and the thinking behind Excelsior and some of the trade-offs that we made, particularly around security, user experience, that sort of helps you understand, there's also another article that immediately comes out, which I think it was in the Daily Beast that said, I managed to hack the Excelsior system in 11 minutes, which was somebody taking their neighbors, their neighbors date of birth and from Twitter the time that they went for their vaccinations and as a result were able to create a QR code in that person's name, which is sort of interesting in and of itself, but then at verification, they've also got to transmogrify into that person and have their identity card at the same time. So, cool story, bro, fun article. But anyway, check those out too. Sorry, Paco, were you going to come in on that one? Yeah, I was going on that one because that was a very interesting trade-off that actually the state of New York have to make between strong authentication and open, I mean, they have the broadest reach. So what they wanted to do is make sure that people could get their passes, right? So they didn't want us to people to register for user IDs, something like that. They wanted to have enough information that we would say you need to, very likely it's you, but if we make it to cumbersome, people won't be able to get their passes. So I think they were working a fine line. We worked with them, we recommended. The model they have is actually very genetic, right? So it can be a strength thing because the idea is that it's a self-challenging question, right? So for example, you could use some of the US Equifax type of question challenges. You can fit it there. They said to focus on information related to the vaccine, but it's more a design question, right? How fine line you walk between the broadest access and the most secure, right? That's a really good point. And actually as another not so great example, and I'm not so proud of this one because it comes from the UK, the National Health Service Vaccine Booking System enabled you to find out based on the page flow whether somebody else had had their first or second stage of vaccination. If you know their name, their address and possibly their date of birth, you were able to put that in instead of your national health service number and the page flow would then tell you you may book on this date or you do not need to book and you do not need to book while it's a proxy for you've been vaccinated. And that obviously in privacy and security circles came out as a very clear floor in the page flow that they've done. And so far as, yes, you could determine someone's vaccine status from putting in certain information. So you had to think very, very carefully about the balance between accessibility, authenticity and security when you go through that sort of flow. I'm just trying to see what's the latest Jim St. Clair question. Shout to Jim St. Clair by the way, welcome. Good to see you here. I'm trying to pickle down through. I need to just filter for Jim St. Clair to see whether we've covered all of his comments. He said, we'll go to this one. Any challenges in applying JSON-LD standards with smart contracts and fabric? So that's right. So we've lined up with JSON-LD. However, we've seen that other encodings are getting traction, right? So VCI using JWT, the EU password using CWT, right? So I think, as much as we love JSON-LD, this is where our heart is. And we have, you know, I think we're actually getting that support in place. We're gonna be supporting different types of encodings, right? And I think, for example, the EU I think picks JWT because of the compactness. So, you know, I think it's going back to the comment before we have to live with multiple standard and technologies. That's part of the game, right? There are gonna be gateways on gateways for the next little while and there's not much we can do about it. Now, the fact is it's just a bunch of translation tables and it's not going to be overly cumbersome, but it is going to be, you know, at least for the EU, there's 30 countries or 28 countries under one standard for North America. Let's see, for Asia Pacific, let's see, or do we actually have to deal with 210 gateways into one? I suspect the WHO is going to transition man that as much as possible and building on things like the EU digital green search or some of the other open standards, you're likely gonna see some convergence pretty quickly. So it will be less of a problem over time, but those universal resolvers are gonna take time to come in. Any other questions in the chat? We've got 10 more minutes and if we can't get enough questions in, then me or Paco are gonna have to sing or do something other, otherwise to entertain you. So I'm pretty sure you don't want that. Jim's good, no way, Jim, not possible. There's no way Jim Sinclair has run out of questions, but maybe you've just been kind to us, Jim. I appreciate it. Any papers you inspired your research? I have a question from Kane. Is this any good papers to check out or any good research in the area of digital identity or self-sovereign identity? Actually, I'll open that one up to Jeff, Daniel, Paco. Where can people do more reading about trust over IP or SSI in general? Yeah, I mean, certainly go to the sovereign side where the hyper leisure India or hyper leisure areas sites are great places around self-sovereign identity. And we've had our previous session where you started out with, again, how do you know? I guess someone's not a dog or whatever when they're typing on the old computer, that old cartoon. So there's plenty of papers there. IBM certainly has, we have our share as well. If you're interested in reading up on digital identity, we have stuff specifically in the federal space around some of our solutions when it comes to working with digital identity in that space, that's one place. Daniel, any articles or stuff that you've come across in recent weeks that you wanna give a shout out to or maybe copy it into the comments if you've got a link real quick? Yeah, I think Jeff cover pretty much everything. I mean, I try to stay on top of the news, just in general with any new sort of products or solutions introduced by not only the large players in the industry, but also some of the smaller size teams or startups that come up with pretty innovative solutions. So I personally, I do have Google Alert put on for any type of new blockchain solution. So I just try to stay on top of it. Yeah, to me, one of the most interesting things again was the choice where we ended up using fabric and the reasons behind using fabric because when I first saw the solution come out, I just naturally assumed, okay, indie areas and it was great to get your perspective on that. Yeah, I mean, it's one of those ones, I think we've covered it and this is one that's going to divide the community in the same way as CoinDesk call us the light beer of blockchains, which is fine, we get it. But ultimately with any technology whether it's the final form of what it should be or whether it provides the digital capabilities in a trusted and secure way to do what you need it to do. We're not using a large proportion of what AI is capable of today, but we are still having impact. We're not using a large proportion of what's possible with cloud in enterprise today, but we will be able to in future, you gotta start somewhere. And we've got to also understand that we as blockchains know this domain relatively well. We feel that we're relatively confident around the art of the possible, but anybody who's been working in blockchain for the last five years also knows that those users of our technology, whether those be our clients, our customers, our governments, whoever it might be is not necessarily on the same page as us all the time. They are not quite as adventurous. They are not necessarily as forward thinking as we are a lot of the time. And the existing standards or security requirements or the architects who we're facing off against are not necessarily as enlightened or as woke as we may happen to be. So there is the practical reality of the incumbents always have the ultimate say in how much they are prepared to be transformed or disintermediated. And I think, I mean, we of course, we're trying to be pragmatic. I mean, we had to build something that scale, we build on fabric, which is the most mature. But I mean, I'll tell my personal views that we want to look at these from a standards, interpretability based requirements and then allow for multiple implementations. That's typically the most successful standards approaches in which you basically let different potential, different implementation, different platforms, different blockchains to support a set of interoperable standards. And I think that's probably what guarantee the broadest access and acceptance of any particular stack, right? Rather than tied to the actual implementation, tied to what are the interpretability requirements. But we'll see how this, we're very interested in making sure that what we built in interoperates with in the areas and as we move up there, the stack. Pak, there's a good one here from, who's coming with us, Cesar, if I'm pronouncing that even close to correctly. How do we look at aggregation or aggregated reports for employers? This is one that came up a couple of times with clients that we've been working with, I know. And I'll let you have the first crack at it, Pako, but there's also some context in terms of which country or which company, for sure. Yeah, so we'll have these asked from several employers in the US, definitely. And of course, what they want to do is as they bring employees back to work, be able to have an idea of what's the status for the levels of risk. We do have actually dashboards that we provide to our employer, the customers. However, we have to explain to them that what we're not gonna do is send them the data directly. Because as we said before, the same principle is individuals in control. So the way you do this is that individuals share their credentials. And we're working with several technology providers in the HR space. You can figure out the names, even companies working with large employees providing HR capabilities. So employees can share the credential, either testing, if testing is required to say come back to the plant, right? Manufacturing floor or vaccination is typically optional. But once they share the consent for the data to be used for, and typically these are aggregated, all aggregated dashboards, right? So it has to be through the individual. We never send the data directly. They share either to say online to their HR system, then verification happens, typically there's a check mark or provided for example, in the employee record so they can enter the plant and everybody's safe. Or it's just for reporting purposes and then it's incorporated. But this has to happen with explicit agreement in consent of the holder. Yeah, thanks for that, Paco. It's always consent-based. It's always user control. But in some industries and some sectors, particularly those where there's high risk or high safety risk or safety concerns, in many cases, those employers are holding complete medical records for their staff. So it's an application. But, sorry, go ahead, Jeff. Oh, I was gonna say, so it's at the application level once that's been gone through whatever the verification application is and then collecting and aggregating the data that way. That's right. All right, here's a really good question from Maria. Are they all different instances? Could a pass I received from New York be used somewhere else with the solution? So if I were in New York looking to travel to Scotland or Ireland or wherever exotic location I wanna go come June, could I have my New York credential be recognized in Europe? So our system will recognize it anywhere in the world, right? So the other question, which is a policy question is what the governments, what kind of reciprocity they have, right? So, but you have a help us credentials, you fly to Singapore, you fly to Malaysia, it's from New York, it scans just as well, right? So that's the idea of having this trust framework that we anchor in the ledger. Got you. And with two minutes left, last question I think from Cesar, we might try and fit Elizabeth's one if we can get there quickly. What do you feel is necessary to educate to convince the market about adopting our blockchain networks? Wow, with two minutes, where do I start with that? I mean, the short answer is don't call it blockchain. Break it down to the digital capability that we're providing and demonstrate objective value. But what we're looking at is we're able to share information in a decentralized way, we're able to collate information and share it in a privacy preserving way that we're able to connect multiple parties together that we couldn't before, that we're able to use and create tokens where that allows unique IP or identity to be attributed to a garment, a vehicle or whatever it is. Talk about it in terms of stuff the blockchain does. Unfortunately, in 2021, walking through the door and saying, here's my blockchain doesn't work in convincing anybody. We've got too much bias, too much water under the bridge. Break it down and be objective. Let me see if we can get Elizabeth's one. Human can share data by selling per data set all organizations or leasing data point over to an organization over a period of time. Is the question, could somebody use or use this platform for selling their own data or monetizing their own personal data if they consent to it? A bit like Brave browser, I guess. Paco, do you wanna, I don't wanna take the official line of IBM saying we support citizens using ABM digital health password data monetization because that's not what it's intended for but could this platform support data monetization in a different pattern possibly? Well, what we support is making individuals, the owners and the controls of the data, right? At that point, it is up to them, right? So we're not intended for that. We're very focused on healthcare credentials, creating trust across the system. But in the end, as the individuals, we're putting everything in their hands, right? We have no saying what they decide to do with that, the data, right? We have, of course, our guidelines and we're very strict. We have ethics reviews of how we sell this and for what purpose, et cetera. So we'll make sure this is a decent year legal ethical purpose, but the goal is to empower the individual. And you think about this, it's a long training which both blockchain and all this credential and technology is conspiring to enable, right? What's gonna come out of this? I think there's a lot of possibilities. Jeff, Paco, Daniel, we're at the top of the hour. Did we do it? Did we get it right? Can we all go to have our weekends now? I think it's officially happy hour, at least somewhere. So thank you guys so much. I'd like to thank also the community for attending and all the great, great questions. Look for more from us for next quarter. Also look for other Hyperledger meetup sessions and check those out as well. And other than that, again, a big, big thank you to everyone and looking forward to seeing everyone at our next session. So with that, it's happy hour. Thanks, everyone. All right, happy Friday, everybody. Have a great weekend. Thank you.