 new thing to do. Okay, we are live on YouTube as well. As soon as my slides load, I will be able to start. Okay, we are getting a good crowd here. I'll start allowing people to talk. Of course, bear in mind that standard zoom etiquette is still in place, so please don't. Don't talk over each other. Hello, Julian. Good to see you, everyone. Okay, so while we wait, how about we have a good crowd but not overly big? So I think it would be great if we can start with everyone just saying hello and tell us where you're dialing in from. We don't need a long introduction, but if you want to share, why did you join the sessions or where you're dialing from that will get things going. So, Karsten, you are already unmuted, so how about we start with you? Hi there, I'm Karsten Leuenhardt and I'm from Germany and work for Define. And yeah, we are at the moment working or starting to work on a POC that is related to SSI. And so yeah, we are very much interested to hear from Evernim about their use case and yeah, so I'm excited to hear about how such a use case can be implemented. Awesome, wonderful. Great, thank you. Let's go further. Who's down my list? Byte, ByteBlock. Okay, so this is Parim here from the ByteBlock and basically I want you to understand more on the effort and I join from India. Lovely, thank you and welcome. Mark Hennings. Yeah, hi, I'm Darligen from Frankfurt. I work with Karsten, so it's basically the same reason we recently started working on this product with an SSI use case and we already talked to Evernim about it and now we're eager to learn more about what Evernim has to offer in this space exactly here. Amazing, Michel Weber. Hello from Frankfurt and yeah, I'm also a colleague from Mark and Karsten working for Define and yeah, we are about to start working with SSI and are interested in this use case. Wonderful, Alexander Kuklin. Okay, well Alexander is working towards unmuting himself. Andreas? Anders Olyama. Hello, Andreas from Estonia. Hello, Andreas. Avram, Sinisha? Hello, I'm dying from Serbia and I'm just investigating about self-serve identity and digital identity. Thank you. Wonderful. Well, thank you. Welcome to Serbia and Estonia. Cool. Ben Gelait. Okay, Ben is still not unmuting. Bernat, sorry. Bernat, would you like to introduce yourself? Hi, I'm calling from Spain. I'm just interested how to apply SSI in the public transport sector. Oh, cool. Yeah. Shirag Sharama. Hi, I'm Shirag from India and I have been joining SSI in the month of March with a new employer. That's why I'm a little bit curious about how it all works. Thank you for letting me introduce myself. Wonderful. Daiv Mitran and apologies for butchering your names. I'm sure that it's terrible, but it's a world full of interesting names. Yeah. Hello, everyone. I'm Daiv Mitran. I'm working with National Blockchain Project, IIT Kanpur. We are working on developing a POC for using SSI for e-governance solutions. Right. Cool. Shirag Sharama. Okay, nope. Girish Shetty. Hi, my name is Girish. I'm from Germany. I'm from Germany. I'm a student studying masters in business and engineering. I'm writing a thesis on data integrity. That's why I'm interested to learn about how this would be a secure way to use. Thank you. Wonderful. Julian. Hey, Marta. It's Julian here. Yeah, definitely happy to see everyone. I would never miss a presentation like this. Well, welcome. Thank you for joining. For those of you who don't know, Julian is our VP of Asia Pacific for hyperledger. A colleague of mine, Lukas. Good to see you. Hi, everyone. This is Lukas calling in from Switzerland. We are Swisscom, quite active in the SSI space as well, and I'm excited to hear more about it from Evernom. Wonderful. Marty Bell? Hi, sorry. Yeah, I'm based in Belfast in Northern Ireland. So yeah, very interested in the content. I met the Evernom guys in Phoenix just before the world went into lockdown. So yeah, looking forward to it. Wonderful. Yeah, that was my last public event as well. Leon McCarthy. Yeah, I'm based in Dublin and I'm developing a POC with some colleagues in the citizen science space. And I'm interested in that aspect of SSI for the user within the web of an application. Right. Well, awesome. Welcome. Rick Cleason. Yes. Hi, everybody. My name is Rick Larsen. And I'm calling in from Belgium. I'm working for Sony as a blockchain architect. And I'm currently working with the RIS framework. Awesome. That's great. Okay. Rocky Rocky. Okay. Michelle Weber. Okay. Hi, Tran. Okay. Kruti Senapati. Sorry. I didn't realize. Good. Do you want to introduce yourself? No. Martha Bennett. This is Kruti Senapati. I'm calling in from India. I'm doing as a blockchain junior developer at Republic Protocol. Welcome. Welcome. That's good to see you. Thank you. So Martha, did you want to introduce yourself? Sorry. Yes, I hadn't realized. I was a new Martha Bennett. I'm an analyst of forest research and I'm following all these developments with great interest. Wonderful. Sam. Hi. I admit James and Andy just interested on the identity space with Evelyn. Lovely. And I also saw Alevdina. Hi. Yeah, I'm working also on blockchain and possible applications for office assign in times of COVID. Wonderful. Well, welcome everyone. That's all everyone that joined up until now. As I mentioned, this is not as the traditional webinar. We do want you to be active and participate. This whole event is held under antitrust policy, which means that if you are speaking up, bear in mind that there might be competitors and there might be people that are listening in. So if you would want to share something, share only things that you feel comfortable sharing in public. This meeting is being recorded and is live on YouTube as well. The slides and the recording will be available after the meeting. Hyperledger in depth is really about being active and participating as you could just see. This is just the start. Everybody's allowed to speak, but let's stick to the good practices, meaning let's mute ourselves while not speaking. If you feel like there's a whole big discussion going on and you can't jump in or you just want to signal, do the raise your hand thing. I'll be observing it and we'll make sure to let you speak. You can also ask questions in the Q&A box if your mic is not working, you don't want to jump in, whatever else. Use the Q&A box and of course feel free for side chats and everything else to use the chat box. With that, I will hand over to our amazing presenters, which is Andy and James. As soon as I, sorry, I realized that I didn't do one thing. I'll stop sharing. Now, Andy and James, you are able to share your screens. Andy and James will walk us through the solutions that Evernum built with SSI, specifically the use case of their work with IATA as well as their COVID work. It's my great pleasure. I'm a huge fan of SSI, so I'm looking forward to this session as much as you do probably. Take it away. Thanks very much indeed. It's a great pleasure to be here. I will share my slides real quick if I can find them. There we go. Excellent. We don't have a ton of prepared material here for you today because we do want this to be super interactive. Really, I think we'll just kick off quickly. Andy and I will introduce ourselves. We'll talk a bit about the history of our involvement with Hyperledger and in particular the Ares and Indie projects. Then we can spend as much or as little time as you'd like on a couple of use case examples that we've got. Do raise hands, interject with questions and all that kind of stuff as we're going through, because that's the point. This is really intended to be very fun and interactive. In terms of ourselves, I'm James Monaghan. I'm head of product here at Evernim where I've been since September 2016, which I think is about 20 years in blockchain years. It's been wild. I'm coming to you live from my very green study. It is actually this colour green, all of this is a fake background here in West London. Andy, do you want to give a little intro? Thanks, James. Andy Tobin. I look after Evernim's business in Europe and I've been with the company a little bit longer than James since early 2016, actually, when all this was a crazy twinkle in our eyes. Exactly. Andy and I have the questionable pleasure of knowing each other from a previous startup venture, actually along with Sam, who's on the call. Thanks for joining Sam. It's great to see you, buddy. We go way back. I think a lot of people, in fact, we could do a quick show of hands for this, couldn't we? From the intros I gather, there's a number of people who are aware of SSI generally, and there's quite a few folks who are familiar with Hyperledger Indian areas, but I'm curious, as an audience goes, how valuable would a brief overview be? Do you want to do a quick raise of hands if you're familiar enough with Hyperledger Indian areas that this would be boring for you, or if you'd like us to carry on mainly because I'm interested to see if we can do something interactive and fun like this? Let's see. Quite a few hands going up. Well, two. That's not bad, but... That's more than one. If we raise hands is the question. There's a button somewhere, isn't there, for raising hands? Oh, one of them's gone down. Oh, dear. All right. Well, we'll make this part super quick then, Andy. Very good. Look, there's two main, actually, three Hyperledger projects that Evanim's very closely involved in, and they're Hyperledger Aries, Hyperledger Indy, and Hyperledger Ursa. Historically, they came out of a common code base, but they've since evolved into three quite distinct and full-fledged projects in their own rights. Real quick, Hyperledger Aries is a set of tools for building blockchain-rooted, peer-to-peer interactions. What we mean by that is you've got some wallet infrastructure for storing keys and credentials and things like that. You've got a client for being able to resolve identifiers, and you've got some protocol handlers for being able to exchange messages between different actors in this ecosystem. Together, if you wire these things together, what you get out of it is what we call an identity agent. That is something that manifests a self-sovereign identity that could be acting on behalf of an individual, an organization, a connected device. It doesn't really matter. Aries gives you a framework. There's a set of RFCs which tell you how to build things. There's also a plethora of code bases that implement those RFCs in a number of different languages that let you go and actually build concrete implementations of identity agents to create all kinds of trusted peer-to-peer interactions. That blockchain-rooted part, that's where Hyperledger Indie comes in. Hyperledger Indie is an implementation of a public permissioned distributed ledger with RBFT consensus. It's built that way to solve a lot of the issues that we saw way back in, as Andy said, 2015-16, where there were concerns about the scalability and trustability of fully permissionless blockchains for identities, particularly pertaining to trusted institutions. We wanted something that was open and auditable and had a lot of the valuable properties of a public distributed ledger, but you knew more than nothing about who the individuals were that were actually writing those transactions. That was what led to the creation of the plenum consensus mechanism and the Indie blockchain that's built around it. Obviously, technology has moved on quite a bit since then, so there are other flavours of blockchains now that are used for anchoring Hyperledger Aries type interactions, but the Indie is the one that everybody is most involved with and the one that's used in a lot of our implementations. Thanks, I covered just a quick bit on the origins of Indie and Aries. Yeah, go for it. I think it's kind of lost in the midst of time being a few years ago now, but Indie used to be a sort of one set of code for doing all of the things in the stack that James has just described. Where did Indie come from? Well, back in 2015, 2016, Evernim wrote all the code that makes Indie work and we wanted that code to be open source to allow anyone to use it because if it was just an Evernim thing and proprietary, then we wouldn't get the global traction that we wanted for this whole principle of self-sovereign identity. We open sourced it all and actually when we also set up the Sovereign Foundation in 2016, September 2016, when I launched it in London, as the vehicle to create an independently operating network, which is a sovereign network and the Sovereign Foundation then donated this code to the Linux Foundation and the Hyperledger project. So that's the origin of it and then that whole stack of code was split into Indie for the ledger layer, as James described, Aries for the agent layer and the peer-to-peer interactions and then Hyperledger Ursa, which is the open source crypto libraries. So what was previously really complex, really expensive, highly sophisticated cryptography was then available for free, essentially, with all of the infrastructure around it to enable you to run this amazing capability that lets you move digital credentials around and do dids and that kind of thing. The origin of some of the other components, like decentralized identifiers, Evernim wrote about 95% of that decentralized identifier spec that is now elevated up to the World Wide Web Consortium. So that's why James and I are in the room, I guess, as we have some history in this one. What's wonderful about that is while it's true that we were very early to the scene along with a bunch of other collaborators, now you look at both those specs and these code bases and you can count tens of thousands of contributions from hundreds of different organizations. I meant what I said earlier about these truly being fully-fledged independent projects, so in no way is this an Evernim show, which is really, really cool. And how they fit together, I think Andy just described the relationship between the pieces, but just in terms of the software identity piece and where indian areas fit, the simplest kind of interaction in SSI is one where you would an issuer, so some trusted entity, a passport authority say, or a club offering membership, anything really, wants to give a credential to a holder, that's an identity owner like you or me or could be an organization, which that identity owner can then use to prove something about themselves to verify, the verifier is the one who reads and verifies attributes of a credential. The way you make that work is that the DIDs, so the identifiers of the public entities like the issuers, they live on a public registry and so we use Hyperlegia Indy for that and the protocol for exchanging credentials and proofs and negotiating those connections between DIDs, that's where Hyperlegia Aries comes in, in our case. So when you think about this kind of canonical W3C style verifier credentials exchange, there are other protocols and other blockchains and other projects that are used to achieve these things, but in our ecosystem, we've chosen Hyperlegia Indy for the blockchain layer and Hyperlegia Aries for the agent to agent communication protocol. So that's where that stuff fits in. Yeah, just a quick sort of demystifying bit as well, James, because at the heart of this, it's what we're doing is essentially providing an ability to move some data digitally from A to B, the issuer to the verifier, via the holder, right, digital data. That data would be the same data as you might print out on a piece of paper, like in a passport or on a bit of plastic, like a driving license, but it's being wrapped in a container, a cryptographic container with some data watermarking on it. The data, when we talk about issuers and verifiers and that terminology, the issuers, they're nothing special, they're just the same organizations that would issue you with some bit of paper or some bit of plastic now, but rather than printing it on a bit of paper, they're going to wrap it in a digital credential and send it to you that way. So think of it like that, really, really simply, there's nothing special about issuers and verifiers, but the same organizations that either give you bits of paper or want to see bits of paper, this capability now enables the data that would be on that bit of paper to be put in a watermark digital envelope with lots of other sophisticated things under the skin that make it much better than paper. So just think of it like that, when people often say who are these issuers, well they're the same organizations who currently issue you with bits of paper at the moment. Yeah, and then I think one point on, I alluded to the fact there are different implementations and different kind of code bases for achieving the same basic construct. One of the things that makes the Indian Aries ecosystem quite special and the reason that we've really emphasized that in our work is the very strong emphasis on the privacy of the identity owner themselves. So there's a lot of kind of blockchain identity projects or self sovereign identity projects that follow the cryptocurrency routes of basically the emphasis is on public immutable records of things and they have some useful properties, that means they can never be taken away, it's hard to dispute them, you can be absolutely certain that the person who signs a transaction possesses the keys that pertain to their wallet and therefore they're probably that person, it's quite useful. But the disadvantage of some of those approaches is it means that you're always that person no matter what interaction you're trying to have and no matter which credentials you're using in which context. And so it could play out a bit like having a giant super cookie that follows you everywhere, not just in your online interactions but offline as well. And you know the canonical example is you know I might use my driver's license to prove I'm old enough to buy alcohol at a shop for example. If that shop were to take note of the serial number on my driver's license to compare that with everywhere else I've ever used my driver's license and build this profile of my behavior that would be considered kind of quite egregious but we know that happens online all the time and because it's made very very easy and so what we didn't want to do is create an identity infrastructure that made it really really easy to dial up that level of quite invasive and kind of anti-privacy surveillance. And so Indian areas have a couple of really powerful features that make it useful. One is that these agent-to-agent connections here that are broken by hyperlegia areas they do not use public DIDs that go on a blockchain there. You as an individual you're identifiers for each of your relationships only matter to you and the other party in that relationship so they don't they go on a public ledger anywhere you can create them for free and throw them away when you're done with them and that's really really important. And the second thing is when you're proving things about a credential you're not literally just shipping that same credential over to the verifier along with all of its attributes and its original signature and things like that. That would be a very simple way of doing it but that would have the consequence of meaning that you're revealing say all the attributes on your driver's license and because you're revealing the signature something that uniquely identifies you everywhere you go. So instead what these code bases include is a really cool way of selectively disclosing certain attributes from the credential that you want to prove and doing so in a way that can be indisputably linked back to the issue of that credential but not to the particular credential itself. And so we do that using a bunch of the primitives that exist in Hyperlegia ERSA for creating zero knowledge proofs based on these credentials. And so that means you could prove just your date of birth or in fact just the fact that you're over 21 for example from a driver's license credential the verifier can know with certainty that that credential was really issued to you really came from the driver's license authority has not been tampered with and hasn't been revoked but they're not learning anything else except that your date of birth is within a particular range because you didn't choose to reveal that. And that's quite a unique capability that there's not a lot of other SSI projects out there that can make all of those promises and Andy's just posted a link in the chat to this save credentials set of kind of principles which we had evident and also the areas in the ecosystem I think feel very strongly about. So we encourage folks to bear those in mind when they look at rolling out self sovereign identity projects and in fact it's a lot of that and we get into the use cases and it's a lot of that that has led some of our partners to choose this approach versus some of the other solutions in the market. So I see Rick has a question. Yes a quick one regarding what you just explained. Is it correctly to say that there is no use case where you would send your entire credential to another party even if that verifier party would like to see all the attributes? Well you could do it. What we've tried to make sure is that that's not the default behavior right which happens to work today is that you're sort of always disclosing. If the verifier needs you know if you're renting a car and they literally need all of the attributes from your driver's license and because that's a legal requirement then there's nothing that prevents you from from sharing that but what we don't want is a situation where actually in most cases people don't need all of the attributes they just need a subset so we want to encourage minimum disclosure by default and so the protocol makes it very very easy to verify to say look I just need your legal first and last name from any one of these 10 issuers that I trust and your agent if you've implemented it using the indian areas projects your agent will be able to go into the wallet find credentials which satisfy that criteria and provide a zero knowledge group very easily to the verifier. So okay so even if all the attributes are required you would still advise to use the default protocol and selectively disclose all of them instead of sending the actual credential. Yeah I would because you want to share the facts either you know the claims within the credential what the verifier probably doesn't need is the the original signature or the DID that is specific to your relationship with the issuer for example those there's kind of unique identifiers that could be used to learn more about your relationships elsewhere than you necessarily needed to disclose in that interaction. So that would be that would be our advice but there are certainly legitimate use cases for for shipping the whole credential over but we like I say we we just feel very strongly that shouldn't be the default. I think another important point actually is there's there's lots of companies kind of jumping onto this digital credential bandwagon if you like and not all digital credential solutions are the same it's really important to realize that. The problem is that you don't realize they're not all the same unless you're quite low down in the detail you're looking at is the issuer's signature shared to the verifier or not right so if you look at those five safe credential tests they they try and give you five things to ask your supplier right or your the vendor you're working with or whoever it is to check that you're not going to be creating a situation that's going to cause privacy black spots and disasters for for holders of data. So as James says the thinking that's gone into how these protocols work has been based on a very high privacy requirement such as not sharing the issuer's signature because if you share the the signature the issuer uses when they sign a credential you share that everywhere you use information from that credential all these verifiers can correlate what you're doing because they can all see the same signature so there's a kind of a wall between the issuer and the verifier there it says no integration needed but also the amount of information shared that's been used to create the credential has been limited such that the verifier can check it but isn't given more data that they need to check it and it prevents the verifiers from colluding behind your back to piece together more information about you than you would want to share. That's a really really great question Rick thank you for that and actually before we about I think this is an optimum point to pause before we move into the use case conversation if anyone else has questions about you know Indian areas and how they have actually helped to to build this kind of enabling infrastructure for for self sovereign identity then then please speak up or wait raise your hand and we'll call on you whichever you prefer. While people are thinking I actually have a question why do you have two separate projects indian areas it used to be just indian now it's indian areas and some people throw Ursa in there. Yeah that's that's that's great yeah so the the reason for that is you know in the early days when when the whole thing just just making it work end to end was was a singular undertaking it made sense for that to be that to be one code base and it did it did everything right the original hypoallergic indie code base contains both the the plenum consensus algorithm and a concrete implementation of a distributed ledger using that and a cryptographic wallet for agents to use and an agent to agent protocol for them to use and it was opinionated about the transport layer and things like that the protocol used and it contained an implementation of the zero knowledge credentials and so on and so forth right so it was it was an opinionated implementation of a identity meta system if you will and what's been great is as the community has picked this up and got involved they've been really fantastic contributions about well actually we could use different ledgers that have different properties like indie suits some projects really well and other people would prefer something permissionless like the ion project from from microsoft for example and so on and so forth yeah other people are very interested in different flavors of agents that that aren't about individuals having wallets on mobile phones for example but might be more about connected devices or so forth and so there's a whole separate flavor of work around the the agents themselves and then finally a lot of the cryptographic primitives that were created to enable these zero knowledge proofs they're based on on 20 year old 20 year old work but they were some of the first like practical implementations of those things and they were useful in other types of projects aside from specifically identity projects and so what that led to was essentially these those three separate components that the ledger the agent to agent protocol and the the underlying crypto primitives each becoming full fed full fledged projects in their own right because they each have a separate community around them so they fit together really really nicely when you're building SSI things but they're quite pluggable and useful elsewhere in in their own right cool any I see marty you've come off me did you have a question oh no I was just getting set up but I mean no I think that all makes sense because the last time I seen I was a bit not confused I remember aries coming out of indy and I was it was aries yeah it was aries I was trying to or I was trying to get my head around but no that that was a good explanation right makes a lot of sense typically you won't do much within the if you're going to implement a deployment of some of the the sorts you'll see in a second you'll be typically interacting with aries from your mobile app perspective or an enterprise integration perspective ursa lurks under the skin there you know if you're a real crypto geek you know dive in have a look it's pretty amazing and indy's used at the bottom layer for the the ledger infrastructure so most interactions will happen with with aries yeah what's great is that there's you know there's for people looking to get involved in in open source though there's projects that can scratch all these all these different itches right so if you're um I don't know back here if you're into consensus algorithms and things like that state proofs you know indy's a fascinating project to get involved with you know at the application layer there are rfcs in aries for doing all kinds of things that are not just related to exchanging credentials back and forth you know people who have looked at what a chat protocol might look like what digital receipts might look like for purchases there's what payments might look like over aries all these kinds of things um so all the different layers of the stack um which would be which would be really great so for folks who are looking to get involved um there's there's different projects that that suit different predilections there as well okay well shall we move on to a use case example that might that might tease out some more questions or just does anyone else i'm just trying to see if no no one else has come off mute so um any other questions or we'll move on okay uh rick do you have a question sorry uh yeah perhaps one quick to better understand your examples yeah i assumed that in your examples you are going to present uh agents identity agents so probably some of them will be mobile yes okay now my question um because in the aries framework we for the majority i think is using the akapai cloud agent which has implemented all the protocols now on a mobile application um i think there is only the dot net implementation so is it okay that we say we built mobile agents by only making a mobile ui and the actual agent is the akapai cloud agent so both work in tandem like the mobile application which serves as a front end ui together with the iris blockchain uh cloud agent that's such a good question rick um because that is that is a point of you know quite active debate honestly you know there's having a having a cloud agent where the mobile ui is essentially a remote control for it um is offers a number of practical benefits um you know it's easy to build scalable cloud infrastructure um there are well-established patterns for how you secure that and things like that and so it's it's um it's a very practical way to get started um and likewise the thin client on mobile um you know the the development talent for that is widely available um it's it's an incredibly pragmatic way to get started um and so that is the path that a lot of people have chosen um it it introduces some challenges though that are not unlike the trade-offs of the legacy identity world which you know self-summon identity tries to get away from which is that it makes you place a lot of trust in whoever is running that cloud agent for you because at the end of the day um you don't actually control those keys and those credentials you are you have an app that issues some instructions to a piece of software that runs on someone else's machine and you hope that it does what what you ask it to um and uh that is you know you could make the case that that is not that different to using a federated identity provider like a sign-in with signing with google or Microsoft Azure Active Directory or something like that um you know where where truly you are you're still a client of the system you're not you're not actually manifesting much agency um there are uh concrete um edge agent implementations that um that run on mobile um and actually you know so at Evan in our connect.me mobile app um and the the mobile SDK that we give to to our customers who want to build their own apps um is a full-fledged edge agent so that the keys and the wallet and the credentials themselves um all live on the mobile device um itself and um the there is a cloud component but it's really just an Aries mediator that is used to relay messages back and forth encrypted messages that it can't uh it can't read um that's that approach is um to make it work well on mobile um I used this phrase opinionated earlier um you know it had to make some implementation choices um to to make it actually work reliably on on iOS and Android um and so there is uh there is an open source implementation of that it's um it's the original um agent to agent protocol that was part of that code base Andy mentioned it uh in in kind of the little history lesson there um it's called called VCX which is evidence verifiable credential exchange um library and so that that is open source um as and comes with builds for for iOS and Android um the the Aries community itself um is is not a big fan of the approach that that we took at Evan in so while that that project is open source and it's not actually part of the the Aries code base and so it's made available as as ever in an open source instead um you know so that's um that that's where that exists you know and this is the this is the beauty of community governed open sources that you know there's a there's a lively debate about the right way to do things um and you know we we welcome that frankly so we we don't get to say hey look we did loads of work we're gonna we're gonna put this in your project and you're gonna take it um you know there's there's a conversation about whether it's uh it's consistent with the direction that that project wants to go so it is worth saying the um uh the Evening Connect Me app and the SDK that it's built on is Aries compatible though James isn't it and actually that um we are open sourcing um all of our proprietary software right now so our our Verity Enterprise Credential Exchange Platform has been open sourced already um you can have a look at it um the um uh mobile SDK and the app side of it is being open sourced as we speak as well um so that does have you know our focus is on you know privacy um by design the the best it can possibly be because it's always difficult to add it in later so get it right from the start um and part of that is having an edge agent that is fully capable fully featured there's a full wallet with the ability to create peer dids on the fly um and hold credentials and create proofs with all the crypto in it so that's what Connect.me is um and the code underneath it um with Aries compatibility is is very capable as well um you can probably show us how it's used can't we exactly and it and it does so I think the point is that it works in its past um it's past the interoperability tests with uh other Aries compatible wallets like Akapai for example so you can use Akapai to issue credentials into uh into our edge wallet Connect.me um and likewise Connect.me can prove to to Akapai verifiers and things like that and so you know think of Aries as both the body of RFCs which is kind of the standards that everybody wants to use for these protocols um and a handful of concrete implementations of those um of those protocols that makes sense right yep well let's crack on we have only 15 minutes left so uh I really want to learn about these cases yeah we'll get lots of good stuff right let's do that then all right oh gosh look at that head it's so um yeah I'll do this I'll do this fairly quickly then because the most interesting part is going to be the discussion um but and also probably some of you have um have read about this uh this anyway um because you can't open a newspaper these days without a conversation about um health passports immunity passports I think everyone is looking forward to the summer wants to go traveling again um these kinds of things um so it's a very it's a very hot topic um and as far as the airline industry is concerned this is why they they saw a 300 billion dollar revenue shortfall last year um because no one is traveling um and that is devastating uh not just for the airline industry but also for all the economies that um that travel both for leisure and business supports um and you know what people are proposing as a solution and they say people this is not technologists this is public health experts and sovereign governments and things like that are proposing that um a a reasonable risk adjusted way to reopen travel might be to have you prove that you've had a recent negative covid test in addition to proving that you have a legal travel document um there's a lot more nuance to it and a lot of policy debate around it which I don't think um I don't think is is our place to weigh in on frankly but but this is what this is what a number of governments and and trade bodies have decided is is the way they want to solve the problem um and so seeing that uh we think gush well there's there's a number of damaging and harmful ways you could do that from a private perspective or there's there's some quite uh quite elegant ways you could do it um so working with iata um what we have uh come up with is an industry solution for this so iata has has conceived of a solution they're calling travel pass which is a framework for verifying your passport at home going and getting a uh a covid test that meets the entry requirements for the country you're traveling to and having the result of that covid test um also stored on your phone and then being able to share with your airline um but also with the immigration authorities and airport staff and so forth um the required proof that a you're allowed to travel from your passport you have a valid boarding pass and you have a negative covid test and doing all that with uh with the privacy properties that that we were just discussing and so that sounds fairly simple um obviously uh you could hand a an opportunity like that to a large tech vendor and they build you a big database right let's say oh no problem hundreds of airlines thousands of airports a few hundred passport issuers easy peasy let's get oracle on the case um and you know that that works to a certain extent until you have to answer the question of well who runs that database and who pays for it and who decides who connects into it um and what do you do about the fact that if this has to be global um there is no one sort of global standard for handling the data governance and privacy concerns and very quickly you end up in a place where you realize um you know iata as a trade body are very well positioned to uh to advocate for a common standard for how you do this um but it wouldn't make a lot of sense for them to build a centralized system with a master record of every traveler in the world's health status that would be prohibitively expensive and frankly quite a bad thing um now there's a as Andy posted a link to in the chat there was a whole kind of 90 minute webinar we did that that goes into detail on this with uh with the team from iata actually you'll be able to find a link to that on our website um but at a high level um the the way the solution looks is is like this so armed with uh privacy enhancing verifiable credentials and the hyperlegia areas and indies uh indie project um you can see how actually if i verify my passport um i could model that as a credential um same thing i can equip testing labs to be able to verify the passport when i show up make sure i'm really me and then issue a covid test result to me um as a result of processing my sample and then armed with my wallet uh both to do online check in and then as i move through the airports and arrive at my destination i'm able to prove only the attributes that are required from those two credentials to show that i am i'm safe and able to travel and so um this looks if you were to sort of fold this fold this down by 45 degrees this would show you that classic trust triangle that almost every verifiable credentials use case ends up coming down to um it ends up is really quite simple um but what's powerful about it is the scale that um building it on these open frameworks enables because not everybody has to use the iata app as long as they use the standards that iata promotes then airlines can embed this in their own mobile app and build their own solution not every testing lab needs to get uh you know a solution from evinem or even from myata as long as they're following the governance process associated with with issuing a compatible credential and as long as they're using the hyper legit areas protocols then um then they're good to go and similarly we're not asking every airline airport and immigration authority in the world to plug into one big centralized system that would be awful from a scalability perspective you know we want to get back to four billion travelers a year and so instead they can all choose solutions that meet these requirements from the vendors of their choice and and go and implement something and together we build a vibrant global ecosystem that starts off with airline travel that can easily expand into not just other forms of travel but a number of other sort of high occupancy scenarios where people are very worried about the implications of admitting people that have unknown health status and so in a nutshell that is the the use case and that's specifically why hyper legit areas and indy enable us to to address it i see loads of chat messages flowing through while i was while i was talking there so this this looks like a good topic for me pausing for discussion on this there's one about the perennial question of what if i lose my phone james and do you want to take that andy sure and so lots of options actually here if you lose your phone firstly um you know you can have your well normally your phone will be backed up and um you can elect to have contents of various apps backed up um so the the first put a call here would be what if i lose my phone question and we have got a really good blog article on this which will have to dig up actually um uh is that what would happen if you lost your paper credentials right so if you lose your paper credentials what do you do when you've got a going get a new set where you should you can't back them up and recover them so back up and recovery is the first kind of port of call there and then you're into other questions about things like um the ability to revoke your wallet's ability to do anything um the ability for issuers to revoke credentials that they previously issued um and also um uh the ability of you yourself to you the worst case scenario right you've lost everything you've got no backup etc that worst worst case scenario is the same as the the best case with paper documents which is you you go start again and you you get them reissued again um so there's a lot of advantages to having digital credentials in the digital wallet and they they can be backed up and restored and this is probably a new business opportunity for maybe organizations like banks who you trust to hold your monetary credentials i.e. your money in a bank account and well maybe they could be a custodian for backups uh as well and releasing them only when they know that um the person they're releasing them to is the right person so um lots of options on that and i'll find the link to the what if i lose my phone blog post for you in a minute perfect and i think it's important also Andy to stress that um you know this is this is not going to be mandatory for travelers at all and so um you know we're not forcing you to have a smartphone uh and to download some app that you might not be sure about you know the the paper-based process um will still need to exist and will for some time um but this this is going to be offered uh to travelers who yeah who will see the benefits in it and i think certainly a lot of a lot of frequent travelers um definitely will right mark uh mark has his hand up um you uh what would you like to say mark yes thank you so much i like this picture it's it's very clear but what i'm missing is who offers credentials to the testing lab i mean at some point the airport or airline will have to deal with thousands of testing labs worldwide and they cannot travel to each of them and check if that's actually legit right so there must be some government or someone who issues credentials to the testing labs so they don't know that they can trust that lab yep absolutely so the there's a the short answer in the slightly longer answer so that the short answer is that um one of the services iata provides to the airline industry is they run this uh this product called tomatic which um knows about all the entry requirements for um every every route um in the skies basically so if you're a citizen of country a with a passport from country uh b with a visa of type c and you're traveling to destination d volna e etc it can figure out um whether or not you can get on the plane and and what what requirements you need to need to meet and so that's used at check-in and all kinds of things to try and make sure that airlines are not boarding passengers um who will be turned away at their destination um and so iata is extending the capabilities of that to bring in um governments uh own requirements about what type of test is going to be permitted for uh for entry so the first thing is to capture okay um you know we require a pcr test 72 hours before before flights or you know we need a rapid flow test to have them in the departure border you know whatever happens to be and they're capturing all those requirements and then they're working um with the airlines themselves who have been very busy in the last several months um signing partnerships with labs in the countries that they operate to provide these types of services and iata is onboarding them all into a registry and then it's a simple trust registry that says okay um these these labs uh which meet the requirements of these airlines which are guided by these government requirements um they when they issue credentials they will do it using using these d id's right so there's a d id for each lab and so um on the verify side you're able to know with certainty which lab it was that issued a credential and then um you can you can figure out if they uh if they are trusted and not by using the iata trust registry but iata doesn't want to be the sole authority of you know what isn't isn't a legit testing lab because as you said number one that'd be hard to scale and number two um that's not really their job their job is is airline travel not um not clinical testing um and so the way they're doing it is in can is consistent with the kind of trust over ip foundation framework for how how governance frameworks work and uh and you can stick a link maybe to that in the in the chat if he's got a sec but um you trust over ip talks about how you can layer in both the cryptographic trust which is this credential came from this d id and was shown to me by this holder with the um the kind of real governance trust of and i know who stands behind that d id and i know what circumstances under which that credential was issued so i can infer some level of trust from that i can make some decisions and there's a whole stack that sort of sits next to the technical stack which is the governance stack um and the trust over ip um principles show you how to how to build that framework up from the d id level through the credentials change level to the wallet level and and so on and so forth so um iata and a number of industry participants in the um good health past foundation things like that are working together on publishing what that governance framework looks like because the goal is for it to be an open collaborative movement that that no one organization like like our attitude needs to run there's registry there's trust registry that sounds like something highly centralized then right correct it's it's a locus of centralization for this particular use case because what everybody here has in common is they want to know that um they want to know that someone they trust issued that credential and so in the beginning iata is acting as as a proxy for that they're saying well look we we have some expertise um not really in the technology level we have some expertise in figuring out what the requirements are for people to travel and so they're piling their expertise into bootstrapping this use case but their long-term ambition is not to be the sole arbiter of um which testing labs um are compliant with which countries entry requirements they they want to put this sort of thing in place but by doing it using trust over ip principles um other registries which could be country specific or could be run by other bodies um they can emerge and iata will be in a position to be able to to step back and not have to run that in a centralized way well thank you it's a question from marty james and we've only got a couple of minutes left but i can try and be a bit quick because i i have to drop off i have another call about to start you see just on the whole losing my phone does does that mean does the the device play a part in the verification between issuer and verifier or or is it really just a wallet one thing goes if i issued a credential to device a and suddenly it was being asked to be verified from device b that would raise a red flag for some people yeah that's that's a really good point um and so there are different approaches to supporting you know multiple devices that have control of the same wallet um and i think it's safe to say that there's no um at the moment there's no one approach that the whole community has agreed on um you know in in the case of a cloud wallet obviously it's very easy because your wallet lives in a cloud and all your devices are basically just remote controls for that so it would be it would be seamless to the verify which device you're using they wouldn't even know um that's very good for a user's perspective but as you said in some applications that might raise a raise an eyebrow from a trust perspective um in evidence products um we've chosen to avoid that particular brand of confusion so we've said well for now um we want everyone to have a primary device um and a primary wallet associated with it um and we we accept that that might uh preclude us from playing in some use cases but what it means is you've got a very strong answer to that question because basically it's either your primary device um or it's not you um so that way you have a very strong guarantee great well thanks very much for that listen i have to go but look that's been really really good um thanks thanks for the time guys see you guys if if everyone has time i'm happy to continue uh if there are more questions that you'd like to ask i think it's more uh valuable than than finishing but i understand if people need to run uh so um yeah i see paul asking if delegated trust for the the i.d.'s allow recovery or revalidation uh path for the wallet yeah i mean recoveries um a really important point actually uh you need to make sure that the right person is recovering the right thing um in the case of loss uh there's quite a few different approaches everything from you know social key sharding uh to you know a kind of um garden-like approach like having a bank look after your backups there's lots of different approaches and they'll differ depending on uh on different use cases um so uh i think the answer to that paul is yes that approach could work um Aaron says how can i stop my credentials from being shared by airports or airlines to others without your permission okay that is a good one so when you provide a proof um that proof is provided down a singular unique channel you have with the verifier um that proof is uh is not usable down any other channel you've you've got it's it's particular to that request that the verifier has made and it's down that pairwise connection that that unique link you have with that particular verifier of course if you're providing some data like my name is Andy um that's wrapped up in a nice secure um watermark cryptographic envelope right the verifier gets that unwraps it unwraps it checks it verifies it and it says Andy and um this the fact that I am Andy was issued by the passport office so that's great they now have a bit of data that says Andy on it they can then do something else with that if they wanted to if they wanted to send that piece of data somewhere else it's just like any other piece of data so you can't you know there's no sort of ability to suck back from the ether um but what you do have is you have proof that you've shared it um they have proof they received it and if you want to then resort to law and GDPR for example if you suspect someone has shared your data without your consent you have a really powerful tool to prove what you shared and when you shared it and for what purpose that comes out of the box uh with with the technology yeah yeah okay we've got a question in the in the q and a as well um so this says uh what will be the disadvantages if we use certificate authorities and centralized repositories instead of DIDs and blockchains to create verifiable credentials as the ecosystem still has to trust the stewards during onboarding of issuers etc and then there's a sub question which is what are the incentives for stewards so it's a two-parter so disadvantages of of using centralized repositories instead of blockchain based DIDs and it's no it's no accident that some of the biggest certificate authorities in the world are involved in in this whole space looking at how you know their processes for onboarding businesses for example to issue them with certificates can be converted into verifiable credentials as well um so there's a lot of interest from the certificate authority space um which you could see as being um them being positive looking at new opportunities and also being defensive as well um the difference here is the um I don't need a certificate authority to set up a digital relationship with another party in this this new world I can just set it up so if I need a digital relationship with James to share some information I can set that up independently of anyone else okay and we can then share data down the secure link and that's a huge uh capability that you know it's hugely important it's not really existed before we've always had to rely on somebody else now with the um protocols in Aries for free anybody can create a software stack that allows two parties to create uh by themselves a secure digital connection and share information across it and that's that's massive that can be used for so many things whereas previously you'd have to rely on a CA to give you a certificate that you can then use and then have to go back to the CA to be checked yeah so it's a way I think I think a way to bore that down Andy is to tell me if you think I'm doing a doing your statement justice it kind of pulls apart the roles of um vouching for the issue of a credential right so this certificate authority does two things they say the person with this ID really is this person um or this company um and then they run a big database of those things and let people access to it um and what using a decentralized pki like uh like an indie ledger lets you do is pull those roles apart and say well um anyone who is qualified um can stand up and say this this actor is this entity um and it's up to you whether you trust them or not um but you don't also have to trust uh anyone centralized entity to run the list of all those things and that can be run in a cooperative and tamper resistant way using a distributed ledger and so that that's really kind of the the trade-off involved in in going down decentralized routes but for some use cases like you know individual enterprise use cases and things like that using a centralized like literally a database for your DIDs would be perfectly practical and and we wouldn't discourage it the only issue becomes when you want to open that up and allow use cases to bleed over from from one into the other and then you really want something that that can be uh open and suitable for everyone um let's see we've got a couple of other ones the common questions on steward incentives actually yeah one yeah that i gave them one from nilesh um maybe i'll just cover that quickly james we did have another use case to share as well which we could probably do but let's let's do the questions first because that's what people are interested in obviously um so what drives the stewards to be part of the sovereign foundation other than to increase the trust in the main net itself so that is a good question so um steward is an organization that volunteers to run a node on the sovereign ledger that could be a node on main net or on the staging net um why do they do it well a couple of reasons really one is they believe in this whole concept and they want to be a part of it and the second is that they may be wanting to launch services themselves um that use this technology and being able to say they are a steward of the network and they participate in running the network is a big kind of benefit for them from a trust perspective um you they are part of the the team of of stewards and you know globally who are making this thing work um so that those are the primary incentives there that we found with stewards you're huge big organizations and small little startups um around the world that are making this thing work and making it possible yeah but it's it's worth noting that it's not required to be a steward um to to participate in this ecosystem so there's there are less than a hundred stewards um uh but there are many hundreds of uh companies building on on hyper legit area and hyper legit indie based solutions so it's a bit like the internet isn't it you don't have to run a dns to use the internet but you will really be happy some people do yeah yeah absolutely um let's see uh other questions uh yeah so there was a question for more details about iR to say yeah you can check the webinar link that Andy posted you can also just google for iR to travel pass and you'll see in iR to zone words um the the details of that um i said i think so far it's okay well i mean gosh i i think if we if we do the next use case we're going to go way over maybe it makes sense to um uh just to see if there's any any final questions or do you want to take take five minutes on the next use case Andy what would you like um um if if you have time uh we could just do a follow-up on say monday the 22nd so next monday and just uh do a session specifically on the uh on the covered credential stuff um i think um martin why don't we just do like a couple of minutes um on this other use case and then i want to just james you'll see i've just dropped in slides 19 to 21 as well so we could cover that off in a second um just a really really high level um in fact let's let's just hit slide 19 first actually could we james because um we can then drop back into this use case so this is a kind of really high level um uh way to understand why people like iR to and others are looking so deeply at this technology um yeah you're gonna have to de-share and re-share on you um being it's being tricky uh here we go presents um and this what i'm going to show you just applies across any type of ecosystem um uh anywhere that you you know you might want to um share data in a in a new way yeah is that the one you wanted yeah perfect thanks um so i mean this is i speak bank specific but it doesn't matter but imagine um a large global bank with many departments many organization organizations within it often for regulatory reasons they can't talk to each other right um or they may be allowed to talk to each other but if you just hit the next slide james um what they have to do to make that work is they have to create loads and loads of spaghetti behind the scenes um uh millions of apis at your large tech companies and system integrators make huge amounts of money from doing exactly this right it's very very complicated and i've been the victim of a number of these projects in my corporate past and it's horrendously painful and they generally fail um what's what they're trying to do is get data from one part of their operation to another and so in this new world of ssi just goes to the next slide james right think of it this way right the customer is the api you give the customer the data because that data can be verified as authentic um the customer can move that data from one part of the business to another part or from one silo to another silo and the recipient silo can verify the authenticity of that data straight away so the customer becomes the api right the customer the user the holder they they take the data and they move it between the silos for you which is is epic if you think of it from an efficiency perspective it's absolutely fantastic so um think of it like that all right that's in the ira to use case all of the silos are the airlines and the airports and the test labs and to try and knit them all together would be really really really complicated by giving the passenger the data the passenger can move the data around the silos for you and it saves a huge problem with apis and uh integration behind the scenes so that's if you can you can take this concept and put it into any use case you want um so just do another minute on the employee mobility use case uh just hit that one james slide which are you going to go up and down isn't it okay um yeah that one there so um imagine uh if you will a massive um healthcare provider in the uk that happens to be the world's fifth largest employer move 1.3 million staff composed of 230 so fairly siloed um hospitals um where employees because of the covid situation have to move around an awful lot between these different hospitals um so the use case here is to give the employee digital credentials about their employee identity their qualifications uh their higher your weather on the hierarchy who their line manager is who their employing organization is and so on so that when the employee moves from uh their their base hospital to um a destination hospital where they have to go and you know respond to some covid emergency they're able to on board and prove who they are um their qualifications and crucially also who they are employed by so that money can change hands right because the destination hospital has to pay the originating hospital for this person um they can on board and prove all that in a matter of seconds as opposed to 24 to 48 hours checking paperwork making phone calls faxing stuff um so a huge opportunity there and uh one that's rolling out at the moment um under the skin it's the same problem being solved how do you get verifiable data from a to b and here they're giving it to the employees who carry it and move it and it can be verified same approach as for iata where it's given to a traveler and they can carry it and move it and get it verified um so just think of that sort of cross silo integration challenge as one of the main things being solved here without damaging the privacy and security of the hola yeah and i think it's worth noting that in in this case one of the reasons they they wanted an open source and standards-based approach is because of their size and scale and as you mentioned they're a truly vast organization you know so they're thinking of this less as placing a bet on a tiny company like evernim and more of you know investing in an approach where actually evernim and a constellation of other vendors will be able to to to bring to bear their respective talents and solve this problem for the whole enterprise and in many ways that's the first time this kind of thing has been possible in the old world you would have to just sign a big contract with a big a big vendor and you know for projects of this size there'd be a very small you know probably a single digit um length list of the vendors who would be candidates and that's going to be expensive and leave you locked in for for probably at least a decade and so you know by by basing this on trust over IP principles and the Hyperlegia Aries framework we've given this this organization the confidence to embark on what is a quite a bold digital transformation agenda so that's that's really really cool and you know what's been cool is in addition is seeing this pattern repeat itself across other enterprises that share this same the same pattern of symptoms because you know from the outside all of us think of companies as monoliths right but anyone who's worked inside a big one knows that they're all similar in that they have different departments different jurisdictions different IT systems different different policies and add to that the fact that not every employee is a full-time employee add to the fact that partners need access to certain systems and the old the old way of doing things the idea that well you just you know what we need is a single source of truth just build a bigger database that reaches breaking point really quickly in these scenarios and so we've seen this same pattern play out with large global technology service providers we have as a customer and also there's a couple of other regulated entities outside of the healthcare space who have the same family of use cases i.e. staff moving around lots of locations really strict regulatory requirements about knowing who their staff are and and this approach works really really well there in a way that the traditional approaches might not so it's been really cool but actually since we've got since we've got i don't know i've got probably another five five or six minutes i'm able to stay on i'm actually really interested we've got 26 folks still on the call i'm desperate to hear what other people are working on actually so if anyone feels like sharing some of some of how their projects are working and and where they found benefits and in particular if you've had experiences which are different from ours i would i would really love to hear that yeah i need to jump for another call unfortunately james but if you're okay to hang on i'm really keen to hear as well maybe you can let me record it andy so you can catch up on the last five minutes that's that's no worries thanks for being my wingman yeah oh there we go there's one from paul oh nice right um lovely to talk to you good to see some um familiar names out there as well and uh good like everyone with everything you're doing i'll leave you in james's capable hands good cheers andy um paul that sounds really interesting can you can you unpack that a bit for us would you might come on off you and just give us give us a few seconds to explain yeah sure um my background is in telecommunications and authentication in a very very very old network infrastructure is really easy to defraud particularly in countries that are probably more susceptible to um corruption than others so more likely non-first world countries now they all connect globally so abuse for that i don't know if you have much of it in the UK but in australia it's prevalent is the ability to spoof really critical infrastructure so being able to allow an individual particularly for phone numbers which can roam globally to assign that as a credential and as long as the the owner which is the issuer which is typically the communications authority for the government at the time i'm not sure who it is in the UK but it's the ac main australia they are the number databases and then they allow carriers to actually leverage that associated with a plan so it's really the individual's identity at the end of the day so being able to retain that identity and move between carriers as your port numbers it should be a credential it shouldn't be sitting somewhere else so it helps helps uh with i guess identifying that you know the person's calling you is actually that person yeah that is a super interesting use case and so how how far along is that project if you're able to say is that the concept phase very early days so i'm probably going to have to reach out to you guys to have a bit of a chat about your wallets and and how we can leverage that on a different infrastructure platform but yeah very very early days well super exciting in in my in my past life i worked at a company that was using the phone number as a second factor authentication on behalf of a number of the large large internet providers and so we were involved in in that very battle that you're describing you know the the arms race against people spoofing numbers porting them off impersonating and things like that so i'm painfully aware of the challenge and so that sounds like a really cool solution cool thanks great uh anybody else in the last couple minutes want to speak up about their project and you know who knows maybe you'll find some collaborators on the call no okay oh yeah seems seems like everybody's a bit overwhelmed or um yeah i mean this session was incredible and i do wish that we will have we would have more time and hopefully we can schedule some time to talk a bit more about the last uh last use case you shared with us um thank you so much for participating everyone and for a great discussion uh i really appreciate it james of course you know you guys did an incredible job uh with um with presenting with facilitating the discussion and everything else the sheer fact that we ran over uh that much shows that everybody was really excited and interested um and yeah uh the last thing that i wanted to mention to everyone is that we have two coming sessions coming up uh one of them is uh uh will be handled delivered by digital assets again the same concept very interactive very full of questions uh on the UTXO and account models and then uh on march 17th consensus will continue with the ethereum and hyperledger series this time it will be tech demos and AMA session on hyperledger besu and interactions between hyperledger community and ethereum community and with that thank you so much for participating everyone safe stay safe stay safe and i'll talk to you very soon thank you thanks everyone bye bye thank you very much for the session bye