 Welcome to the Aries demo session, I'm Steve Curran, I'm a consultant for BC Gov and it's kind of time with BC Gov to move on Aries, Aries Maintainer also do have an edX course that we did on Aries a year ago and we're updating it now so a lot has changed in the year. So I thought I would start with an overview of what Aries does and give that quick introduction to it, I've got a little demo to show and then we can get into a summary of what Aries is and questions so feel free to ask questions, my demo, my audio is a bit unclear. Okay, I'm not sure why there was an echo, I'm going to have to keep going because I don't have a lot I can say from it, I guess let me make sure one more thing, yep I've got the right audio going, I'm just going to have to continue and we'll see how it goes, please give me feedback if it's still bad. So Aries is built on the use of verifiable credentials so let's go over the credential model that you're seeing on the screen here. In the credential model you have an issuer, let's stop paper for now, an issuer is some authority that gives a piece of paper to a holder and that piece of paper might be a membership card, might be a driver's license, might be a passport, to give it to a holder the holder holds on to that piece of paper. From time to time, and that ends their interaction with the issuer, from time to time a verifier might ask them to show that piece of paper and the verifier would scrutinize the document, see if it's forward or anything like that. The verifier would decide at one point if they accept the document and proceed on. So Aries allows you and verifiable credentials allow you to extend that into the digital world. So the way verifiable credentials work, that's not what I wanted to do, is an issuer would write cryptographic information once, write it once to a blockchain, a ledger, some sort of public area where they publish it. Once they've written that they can sign, verify the credentials, digital documents that they sign with the cryptographic material, a private portion of the cryptographic material that they publish, the public portion on a ledger, they give that document to the holder and again, just like in the paper world, that ends the transaction interaction. At some time later, a holder and a verifier start connecting and a holder presents a proof to the verifier, not the original document, but a proof that they have the original verifier would leave the cryptographic information from the issuer from the blockchain so they know what's in the proof and how to verify it, and then they verify that proof. So that's the interaction of verifiable credentials and Aries, a ledger Aries is a project to implement the various roles, agents that perform the various roles, the issuer, the holder, the prover, and the verifier in a verifiable credential role. So that's what Aries is. Let's see in action, I'm going to try a video here. It's a board or sound interaction. So this is an example and brick formula to design code credentials if we wanted to do that. So this is a demo that we put together just to share the idea. So the idea there, the person logs into a place where vaccination, proof of vaccination information is available. They move and select a credential, a proof of vaccination that they want to put in, one of their vaccination records. They select their wallet, it's a wallet that they can use to provide that. That scans the QR code, they get offered a credential, and they accept that credential and load that into the wallet. So now they have that in their wallet, they have this vaccination credential. Next, they can share that wallet. So they go to a verifier and they scan that QR code, they can ask them for data from their wallet. They provide that information. So that was a quick overview. I didn't want to take a lot of time in doing a demo. There we go. Okay. So ARI is in action. So that demo was done by two governments, assistant integrator, independent of the two governments. There was three ARI's components used. ACAPI is one, ARI's Framework.net, using a transit mobile wallet. So that was the wallet we saw. The wallet verifier was implemented on ARI's Framework.net as well, using the transit platform, which is a vendor in the United States. And all of that went from zero to that full demo in a week ago. So, and done by people not core to the team, for example, at PCC. So that's the type of effort that it takes to do these. So what is ARI? And by the way, if anyone has questions and so on, I guess there's a Q&A over there being asked. I just wanted to check, but feel free to ask questions, so that once I get through this, we can start to ask. Yeah, so the demo had no sound on it, so it was good to hear anything. So a set of messaging protocols. So ARI's is made up primarily of protocols that are defined in a protocol loop repository called ARI's RFC. This is linked to it. The basis for interoperability. So you've got a bunch of protocols, and you've got a bunch of implementations. How do you make sure that the implementations line up and work together? So the way we've done that in ARI's is we define what's called an ARI's interop profile, and that defines the set of ARI's RFCs that the community agrees to coordinate on. It's a subset of the total RFCs, and it locks in the RFCs at a certain version. So we make sure that everyone's building to the same thing. Version one of the AIP was done in 2020, and just the other day completed version two. And so that is involving capabilities we can do. As well, there's ARI's interoperability test suite, and this is linked to it, and it shows what implementations there are, which ones have implemented a test suite, and how are they doing interoperating amongst the implementations. As I mentioned, ARI's has open source implementations. There's actually five major implementations and two mobile apps. I've got a link to all of them on a coming slide. So lots of code in the open, multiple closed source implementations. So a number of organizations have built their own. They've just followed the RFCs that are defined and built their own implementations, and then many, many deployments. These are the actual codes that people have deployed that code over and over. We don't know how many, since I work closely on ARI's CAUTI, I don't know how many points there are, and how many people are using it. It's very, I see it all the time, and when I come across different people using ARI's and doing different things in verifiable prevention communities. And understand that issuers, verifiers, holders, approvers, all of these things can be taught in any combination. So an issuer could also be a verifier. They actually are working on some things where they're all free-roll. On an enterprise side, a mobile app could have all free-roll. Lots of questions are letting in what you can do with it. Current direction today, the majority is AIT 1.0, and most of the deployments are based on HL-winding, ledger and verifiable credential format. Indy is very involved. We're very involved with Indy there. AIT 2.0 really extends it to other ledgers, other verifiable credential formats. Indy, based on LD, plus other verifiable credential formats that the CDF provides. So those are the things you'll see. Underlying messaging within ARI's is a thing called DIGCOM, DIG communications messaging in one. DIGCOM P2 is being defined again. And so last slide is just a list of all of the projects. This is posted in the my schedule, schedule.com, schedule.com, and there's a FITLE link. This is a FITLE link. HGF 2021 ARI. So there we go. I'm looking at the questions. Do you think it's better to join Sovereign for identity or is it better to create your own blockchain? It is a lot of effort to bring up an Indy network and to publish your own network. So you can do it. It could involve a set of enterprises joining together to do that. And there are a number of reasons to do that. But certainly Sovereign gives you, Sovereign is an instance of Indy and it gives you a good way to start with very low effort. Basically, you can download Appify, for example, or one of the ARI's implementation, deploy it, try it to your legacy system, your business app that you're trying to use to be an issuer or a verifier. And Sovereign lets you start very low effort. Much cheaper than, for example, to build your own. I read that one of ARI's protocols is to buy and sell. So certificates can be used as assets. Generally not. The idea of the model is not issuing a credential to from an issuer to a holder for them to present later. There is no there can be an asset transaction tied to Indy. As far as I know, I don't think there's any protocols and none in the interrupt profile to allow you to do that kind of asset exchange. So it's not intended for, you know, prevention of double spend and other things you might use for assets. Yeah. So how does this work in parallel with authentication? So the idea here is something like we have a use case and there's one we have, for example, with the Ministry of Justice wanting to know who's allowing access to lawyers and lawyers that are currently processing. The way we do that is the law society, which is the membership organization that allows lawyers to operate. They're legislatively legislative authority over that. They issue a credential to a lawyer. The lawyer keeps it in their wallet and when they go to authenticate a system that requires you to hear a lawyer, they present that. It would be verified and so there's, and in doing that there's no need to integrate with or come back to the law society and they can't track what the lawyers are doing. They just use the credentials that the lawyer holds. If the member becomes for some reason out of loses their membership of the law society for whatever reason. They require, they have a criminal charge or whatever. The law society can revoke the credential when the lawyer goes to use that credential if the addict is not there. Let's see. I think that's most of the questions any other questions people have from this. Are there plans to support hyperlegislative fabric? This is one that we get a lot and it's quite interesting to decide you don't really know, I haven't done enough to figure out what exactly that would mean. So it's certainly a fabric client could be verified to allow access to it, but I don't know how more concretely integrated it would be done. I don't have a great answer for that. Is there a guide to move from NDSDK to ARI? Basically in AIP one in all of these libraries except for the one NDSDK is already built into it and so it's already part of ARI. So any protocol that uses Indy as the either ledger or the decentralized identity is, or uses Indy for the verification of credential format already has NDSDK basically ARI is spun out of creating these clients and agents for Indy to become an independent project and enable it to use other ledgers and other verifiable credentials like that. Are there any integrations with IndyC? There are, the big thing that's happening all around is the use of ARI for potential for authentication. So that's the big one right now is a possible use case. We'll see where that goes. So what's being done for businesses, I know for instance, Indy Ledger uses ARIs for their customers they built it into their own app and embedded it into their own app which is the protocol and so they issue a credential to their clients and then when they call the data center when they call the call center can you use identities on an additional fabric panel instead of setting up Indy separately. The ARIs framework go actually has an integration with Fabric where they're storing that minimal amount of information necessary that the public use for the identifiers for an issuer and for issuing credentials on Fabric that is definitely possible. Yep, so that can be done. I think we're out of time hopefully that gave everyone enough information if there's no more questions we'll wrap it up there's an intense little bit of session it's interesting not to be able to have conversations with people I hope next time we get to do this in person so we can actually go back and forth on questions rather than I think hopefully the slides as I say the slides are available in the skedge.com and are also available as noted here here on the slides definitely you are out there. Thanks all and that's the end of the session.