 I'm Andrew Whitehead, an independent developer working with the government of British Columbia in digital trust services. This is going to be a session on building the next generation of ARIES agents. So hello, thanks for coming out. So a quick introduction to the work we've been doing at BC Gov. ARIES Cloud Agent Python is something we've been working on for, I guess, two to three years now. It is a sort of agent and agent framework written in Python for developing ARIES agents. It lets you hook up a controller written in your preferred language to communicate with the agent over a REST protocol. We use it ourselves to issue credentials to the org book, which acts as a holder of credentials. Those credentials are business registrations for the province of BC, as well as related credentials having to do with certifications. We can put credentials in there, such as whether a business has been registered as a green organization. A lot of what we do has been based on Hyperledger Indie, especially the non creds credential supports, which relies on an Indie node ledger, an identity ledger, which is permissioned and doesn't involve any mining. We don't store any credentials on the ledger. They're only communicated peer-to-peer. We encourage basically single use didcom connections for that. And the non creds credentials have support for revocation, where the registry is essentially published to the ledger, which allows it's one of many measures taken to avoid exposing any details about the holder of a credential unintentionally. So ACAPI, we've been around a lot. It's quite popular in terms of contributors and implementations. A lot of people are taking this framework and using it to build their own applications. And we've started to run into some limitations of Indie SDK for our own use. Our particular deployment runs on OpenShift. And we like to have several agent pods running, all issuing from a shared wallet, or in the case of the org book, receiving and storing to a shared wallet. And because of the architecture of the SDK, where everything is bundled together, you've got your ledger clients, you've got the wallet handling, and you've got the credential operations. Sometimes we were finding that our performance was limited by that, but also the flexibility of those components was a bit more limited. So we've been on about a year project, I think, of separating some of this functionality into what we call the shared components. And I'll introduce some of those components and how we plan to use them and make them more available, more convenient for others to use as well. Our hybrid repositories, apart from ACAPI itself. There's the IndieSharedRS repository, which contains IndieCredits, IndieUtails. There's IndiWQL in there. These are Rust crates, so fairly low level for most implementers, but we take these components and add language wrappers on them. So at the moment, IndieCredits is available for Python as well. IndiVDR is the ledger client library, and Aries Askar is our generic storage back end, which is not very opinionated about what you store in there, but can be used to develop specialized wallets. There's a few links there below if you need to explore the projects. Otherwise, I think you can just hit up Hyperledger on GitHub and search for us. All of these are tagged as at least Aries. Part of our motivation comes from the set of standards behind AIP 2.0. This is the Aries Interop profile. So at the moment, AIP 1.0 is in effect. There are, I don't know how many implementers, I think at least a dozen now, that are conformed with AIP 1.0 to different levels, which means they can interop with each other. The first requirement there is generally peer connection establishment. For AIP 2.0, the data exchange protocol has been introduced. This replaces the earlier connections protocol. The out-of-band protocol also kind of spun out of that effort. So connection invitations are now represented as out-of-band messages, as well as certain other kinds of requests. So a connectionless presentation request or connectionless credential offer is possible using that protocol. And we have newer revisions of the protocols used to exchange credentials, either to issue new credentials to a holder or to present indie credentials to a verifier, as well as the new BBS Plus credentials, which are being introduced now. And one point that isn't listed here is the didcom v2 envelope formats. So that's going to be a big part of supporting AIP 2.0, as well. As the envelope format has changed, it's become a little more standard in terms of being a JWE with more widely implemented encryption algorithms. So the first project contributed to Hyperledger was IndieVDR, as part of this effort. Separation of the shared components. IndieVDR is directly adapted from Indie SDK code. So just pulling out the Ledger client code, which uses 0MQ to connect to the verifier nodes of your Indie SDK Ledger, be it sovereign testnet, mainnet, or a local Ledger instance. We use Von Network mostly for that to boot up a quick development Ledger on your local machine. So IndieVDR lets you read and write the Ledger written in Rust, part of the code adaptation meant moving to Async in there. And it has language wrappers written for Python, Go, and Node.js. Python is most complete there. Go is, I think, pretty close. It might be missing one or two request types, and Node.js is more under development. There's also an FFI for a function wrapper. So you can call it directly from C desired. And IndieVDR includes a basic REST proxy. It's called IndieVDR proxy. And you can just point that at a Indie Node Genesis file, run the executable, and it provides a REST interface to read and write from that Ledger. We are also using IndieVDR directly in Indie Node Monitor and Indie Tail server now, as opposed to using Indie SDK there, because all they really needed to do was connect to a Ledger. Under Indie SDK, you'd have to create a wallet before you could load the Genesis file, set up the pool, and start interacting with the Ledger. So it gives us a little more freedom there. And if any additional features are added, you can upgrade that component independently or not, depending on what your needs are. IndieCredex was the second fork of this development. This was also extracted basically directly from Indie SDK, some adjustments to the API. This provides the non-creds credential handling. It's everything you need really to be an issuer or holder or verifier of a non-creds credentials. These use CL signatures, and they're inherently tied really to Indie Node Ledger instances, because that's where you will find the schemas and cred defs, revocation registry definitions, and entries all published, as well as the key information about the issuer of credentials. IndieCredex also has a Python wrapper and foreign function interface. The major difference here is that the methods, as called, will directly take the credential cryptographic inputs. So you're not giving it a pointer to something in the wallet to go and look up. You are going to your wallet fetching the objects that it needs and passing them into the non-creds methods. That obviously takes some careful operation to avoid leaking those objects, but we trust you to do that on your own. In general, you want to use a framework for these things, anyway. So Acapai does it in a way where the buffers are generally passed around with zero copying into memory managed by Python itself. So the buffers are always zeroed once they're released. IndieCredex doesn't do any threading itself internally, because it tends to be CPU intensive, especially things like generating signatures or creating a new revocation registry. So it leaves it up to the caller how many threads they'd like to run to perform these operations. When we use it in Acapai, for instance, we're running in an async framework. So we tend to use a thread pool for all of these operations. And the most recent components that we've introduced is Erie's Ascar. That is sort of lightly based on the design of the IndieWallet, but it doesn't really share any genetic information. The 0.2 release of Ascar is coming out shortly. There's been several overseas there. And that introduces the new Ascar crypto crate. That does, it offers generation and representation of all the key types that we need at the moment for an Erie's agent. So there's everything from Chacha encryption, various AES, DM, key wrapping, ED25519, of course, X25519. And there's basic BLS key creation that will be updated soon, as well as the addition of BBS signatures. At the moment we use the Matter Global FFI BBS signatures Python wrapper for the BBS signature generation, but that will be moving into Ascar as well. Ascar crypto itself supports the ECDHES and ECDH1PU, GWE encryption algorithms up to the latest drafts, as well as a generic encrypted key value storage. Internally that looks a lot like how the IndieWallet stores records in that there's just a large items table. If you're using normal database tools to browse the database, you can't really discern anything. All of the records are encrypted there. It allows searching for these records by encrypted or unencrypted tags, as well, which is the primary way of finding information once you've stored it in the encrypted storage. There are SQLites and Postgres storage backends, much like in DSDK at the moment. Both are built in, so it's not a separate plugin for Postgres. We'll likely be adding more storage backends there as we go along. And at the moment, there is only a Python wrapper and foreign function interface. Love to have additional language wrappers for Ascar here. And as I mentioned later on, Ascar crypto is designed in particular to be used in isolation. So if you don't need the storage functionality, you can still use all of the key handling and encryption operations there. So a primary goal of this project was reusability. We wanted each of these components to be useful on their own. And for implementers that didn't need all the functionality, they could just pull in one or two of these components. As we go along, we may or may not be focusing on the non-creds credentials, for instance. We may be doing more BDS-plus credentials, which could obviate the need for IndieCredEx there. So both IndieVDR and IndieCredEx allow you to perform these operations without a wallet, which was a primary restriction of IndieSDK. And we're aiming to support multiple language wrappers so that the same tools can be used, whether you're building a framework in Go or JavaScript or Python, as we are. Ascar crypto, the core functionality in Aries Ascar is no standard compatible at the moment. So it should be able to target embedded hardware, although nobody's tried that yet. And it should be compilable for Asm as well. Although, again, that's an experiment that hasn't been tried. And that crates on its own, gets you a long way to supporting Digcom V2. It doesn't do the JWE construction and deconstruction, but it gives you all of the encryption algorithms needed. You can also generate your BLS keys for doing BDS-plus signatures. And shortly, that will be integrated more directly. So now that we have these three components, the next step is re-architecting Aries Cloud as in Python a bit so that users of the framework can switch from IndieSDK to the new components. There is a shared components branch, if you'd like to check it out. That will be merged in preparation for the 0.7 release of Acapai, where you can try out the new backend experimentally. So each of these components has a Python wrapper, and they're installed from PyPy as wheel packages, because the core of each of these is a shared library written in Rust. Acapai uses dependency injection which means that in general, the protocol handlers are highly reusable. They don't need to know whether you're running IndieSDK behind the scenes or whether you're running the new shared components. So in general, it hasn't been that difficult to add support for the new components. We just change which implementations get injected for the various interfaces that the protocol and service handlers request. So using the new backend, you request the IndieLedger base interface, and you may get back an IndieVDR ledger implementation as opposed to an IndieSDK ledger implementation. There are IndieCredex issuer, holder, and verifier implementations. There's the asker storage, implementation of base storage, and the asker wallet, implementation of base wallet, as well as for 0.6, we introduce the concept of profiles, which roughly corresponds to an identity, which may or may not correspond to an entire wallet. Profiles also have sessions, which introduce some basic transaction management. As we go on, we'll be introducing more support for transactions in protocol handlers to make sure that logically grouped operations all proceed within a transaction. And a large part of the reason we were able to switch these backends as well is the high rate of unit test coverage in ACAPI. So every PR goes through, I think, about 1,200 unit tests at the moment. We have over 98% code coverage. And we don't intend to change that with the new backends. But for instance, just taking all of the existing wallet and storage tests and running them against the new backends goes a long way to knowing that we can just plug those in and they will work equivalently to Indie SDK there. We also require fairly stringent code formatting of any contributing code so that our divs aren't full of changes just due to IDEs reformatting things. Current status, all of these packages are published currently for, I should say it's x8664. Additional platforms would be another important area development. We just need to work on the CI, which all runs on GitHub at the moment to publish those additional platforms. You can check out shared components very soon. You can check out ACAPI 0.7 where all you need to add is wallet type ASCAR and make sure you've installed the requirements. There's a separate requirements file for that. Or you can install ACAPI with the ASCAR feature flag. Should support all of the same protocols that it does now. And very soon you'll be able to take your Indie SDK wallets and run a script to migrate it to a Aries ASCAR wallet. I will stop for a second there to see if anybody had questions. See, we've only got five more minutes. Nobody's posted anything, so yes. So Jakob Kochi was asking, does base storage represent the non-secrets part of Indie SDK? Yeah, essentially that is the parallel. ASCAR storage is just a generic interface for fetching and retrieving records that are identified by a category and a name and are stored encrypted. The ASCAR wallet interface provides more key management, things like signing with a key and verifying with a key. And management of your dints in the wallet. Philip Ross is asking, can I use only some of the new components or do I need to switch completely? So within ACAPI, there's only the one flag. If you're using an ASCAR wallet, then you're using Indie BDR to connect to Ledger. And you're using Indie Credex for your credential management. That's because we can't really take Indie SDK and just use it for credentials. You kind of need to use it for everything. But the components themselves are independent. At the moment, Python packages. And there's nothing stopping you from using them in isolation that I know of. I should mention on this slide that documentation is still lacking. I need to publish documentation for the Python APIs. The Rust crates generally are fully documented, I believe. The structures and methods have at least some description of what they do. But we need proper fleshed out readme's quick start guides. And documentation of the wrappers as well. Dan Yamamoto is asking if I could elaborate on BBS Plus support and the canonicalization listed here. I threw that in actually based on some comments by Brent Zendal at Evernim that they're looking at a message canonicalization format based on Microsoft's apartment, I believe. And I'm still looking for more information on that, actually. The 2021 signature suite is, as far as I know, currently a set of notes by Mike Lauder. So we're following that and looking to contribute as well. We've been doing a lot of work on BBS Plus credential revocation at the moment, which seemed like a big gap as far as our usage is concerned. And I think we have a good solution there, which will be publicizing shortly. As well as our other future plans, we'd love to see uptake of these components in existing frameworks. Didcom, RS, for instance, I've seen, that's under the diff banner, but it re-implements some of the things that are in it. Ask our crypto and it could easily use the ECDH1PU implementation there. Vaughn Network as well, we'll be switching to IndieVDR. I actually had a branch that switched over to that for quite some time, but it hasn't become the main branch yet. I think we've only got about a minute left here. So if there aren't any more questions, I'll wrap it up there, I think. Thank you very much. Of course, you can look us up on GitHub if you'd like to contribute, watch for the new releases of Acapai, if you'd like to test the code out yourself. And we're thankful for any contributions. Everything we do is open source. So we'll rise all boats together, right? Thanks very much.