 renaming doesn't really seem to work. Okay, I'll try to rename you directly. Hang on, all right. Perfect, that worked. Hey, and we are up and running and we are now live streaming and I'm going to, hang on a sec, share my screen again. And then I'm going to do a backup recording, record to the cloud, great. All right. Welcome everybody to the Hyperledger Foundation Workshop, Hyperledger Aries Framework JavaScript 0.4.0 release, setting up an agent, initial and credentials. Thank you all for joining us. This session is being recorded. It is going to be, and it is being live streamed on the Hyperledger YouTube channel. I'm going to post some links in a second in the chat once we kick this off. But I want to thank everybody for joining us. As with all Linux Foundation meetings, this is held under the Linux Foundation Antitrust Policy. If you have any questions about these matters, please contact your company council or if you're a member of the Linux Foundation, feel free to contact Andrew Uptegrove of the firm, Gezmer Uptegrove LLP. I would really like to thank the three organizers of this workshop, Ariel Kareem, come on, Ariel Kareem and Bernd. All of Hyperledger is powered by contributors and maintainers and users of this software. If these folks didn't exist, we wouldn't exist. And we cannot thank them enough for sharing their knowledge. And quite frankly, all the hard work they've put into Aries Framework JavaScript, just in general, but also to get us to the 0.4.0 release. And with that, I'm going to stop sharing and turn it over to Kareem. And I'm going to start putting some links into chat. Kareem, it's all yours. Section, thank you. Sean, Bernd, it's during my screen. Yeah, okay, that's working. Cool. Well, welcome everyone and thank you for joining. As Sean said before, well, my name is Kareem and I will be giving this presentation together with Ariel Gentil from 2060, also a maintainer of Hyperledger Aries and Bernd Sundek, who works at Animal as well. Let me see if this works. Nope, that didn't work. So, good overview of what we're going to do. I'll start off with a small introduction. As this is about the 0.4.0 release, specifically, we will have an overview of the release where after we will, Bernd will show you a little demo that he has prepared. After that, he will show you a few code examples of how it has actually looked to work with the 0.4.0 release. We'll have a short look at the documentation, a look at what is on the roadmap and what's next. And at the end, we will have a question and answer session which we did this last year, similar session for the 0.3.0 release. There were a lot of questions and we had to cut it short. So, we expect to have some, or to spend quite some time on the question answering session so we can answer all the questions you might have. So, first of all, introduction. Stances are Hyperledger, Hyperledger, well, a global Hyperledger meetup. I want to quickly touch on what Hyperledger Aries from JavaScript is, what it isn't. Sorry, I see that I don't have my camera on. So, yeah, a quick introduction on what Hyperledger Aries from JavaScript is. I will not go into details of self-trafficking identity and all the, well, yeah, all the things and concepts around that. If you are interested in that, then I urge you to look up the previous session we did on the 0.3.0 release because that goes more in depth into what self-serving identity is in general, but this is really more specific to the 0.4.0 release. So, but to summarize, I need to quickly go over it. Aries from JavaScript is a framework for implementing self-serving or decentralized identity solutions. I use both terms because I think decentralized identity is the more popular term nowadays. It is based on Hyperledger Aries standards, which is a collection of RSEs or standards that are implemented in multiple languages. You also have Aries, CloudAge, and Python, for instance, and this obviously is the JavaScript version of it, and which will become a little bit more relevant few slides ahead, but Hyperledger Aries was born in the Hyperledger in the project originally. So, because it's a JavaScript framework, the cool thing I think what is cool about it is that it's a multi-platform solution. So, that means basically you can run on the server side through Node.js, but also mobile devices if you use React Native. So, this is the typical, again, I'm not gonna go into the details of it, but this is the typical SSI diagram. You, I'm sure you have seen if you are somewhat familiar with SSI. So, you have in the SSI, which is self-suffering identity, in that ecosystem, you have usually a three rows. You have the holder, someone who receives credentials, a verifiable credential, you have an issuer, someone who issues them, and a verifier that is interested in verifying it. And additionally, you see at the middle, in the middle, the bottom middle, I guess, the verifiable data registry, and that is often a blockchain, but it doesn't have to be a blockchain per se. And as I mentioned on the previous slide, it is a multi-platform system. And the cool thing about that is, is that it can, well, yeah, it can help you create solutions for all these roles, right? Because a holder in a lot of cases has a wallet, a mobile application. So, for that you would use React Native. But in Azure and a verifier, often run some kind of server architecture, but then, again, you can use the Node.js runtime for those kind of solutions. So, it really covers all of these things, and we really do our best to keep, well, the features that we implement to make sure that they run on all platforms. So, if you use Aries Firmware JavaScript, which I will, by the way, abbreviate by AFJ a lot in this presentation, but if you use AFJ for, well, your holder, your issuer, and your verifier, then you should be, well, yeah, they should be interoperable automatically because it's the same framework. And next. Yeah, so let's go over the release overview. And the most primary thing is modularization. That is, we have put a lot of work in making the framework more modular, and that work already started before. So, in the zero, I believe, zero, two, zero, everything was one big package. And in the zero, three, zero release, we already started, like, well, implementing new features in different packages, different module. As you can see, we have extended that work quite drastically in the zero, four, zero release. So, I will quickly go over a few of these components. I'm not all of them, because they are not all that relevant, but on the left, you see in blue, the core. And the core is just, well, as it has the core framework, it is everything you need to run a, well, to run the framework. Below that, you see two direct native package and the node package, the two in gray. Those are basically the dependencies you would need for each platform. So, if you're running, or if you're creating a mobile application, you would use the react-native dependency, the react-native package. And if you are running a server-side application, then you would use the node one. Next. Whoops. So, this is just a copy of the right side of the previous slide. So, what have we added and what has happened exactly? I've put a little legend on the bottom, but in essence, we have some new functionality, which you see in the green tiles on the right. And we have packages or modules that were already present, that's the purple ones. We have a package, the ND SDK package in yellow that has been moved out of the core to its own package, its own module. And we have shared components, which you see in orange, which I will explain now in the next slide. Oh, there were two slides. So, for those who don't know, as I previously mentioned, Indy or Aries was born in the Indy ecosystem and Indy is a, well, right now it's a ledger, a identity-specific ledger under the hyperledger umbrella, but they realized the maintenance of the Indy realized at some point, hey, we need, just the blockchain is not enough, right? We also need software standards protocols for agents. So, the issuers, the holders, the verifiers, they need to exchange information. They need to exchange credentials and we need protocols and specifications for that. So, along with Indy, and I should say Indy nodes, which is a separate software component, they created the Indy SDK and the Indy SDK, as I suggest, is the SDK that you can use, you can use to communicate with the Indy networks. So, an example that people might know is Sovereign, that's an Indy network that is used in production. And this Indy SDK, it did a lot. It did the, which you see all the way at the bottom, it took care of the communication with the network. No, the bottom of the first, yeah, that one. It takes care of the communication with the Indy network, but initially, it also takes care of storage. So, the credentials and other, well, related data objects and models, they are stored encrypted. And that is also something that the Indy SDK did for you. So, it basically also provided secure storage. It provided cryptographic functionality that we needed. Under the hood, it would call Ursa, which is another hyperledger project. And it also took care of a lot of Anon Credits related functionality. And Anon Credits is the new name for what used to be the Indy credential format, which is a specific type of format out to represent revenge. But a lot has happened in the meantime. Anon Credits, the Anon Credits credential format, so the Indy credential format, what used to be the Indy credential format that got sort of separated from the whole Indy stack. And has been renamed to Anon Credits and now is really a standalone credential format standard. And in the meantime, we have, and that was already the case in the 030 release, I believe, we've added support for other credential formats like the famous W3C credential format. We have added support for JSON-LD back then. So a lot of movement here. And as a result of Indy being this one giant rust dependency that does everything, basically, the result of that is that if you would have used every framework JavaScript, you just issue and or verify or hold or whatever, but specifically W3C JSON-LD credentials, well, yeah, you needed Indy SDK to store stuff. So you would automatically also include the logic that is related to communicated to an Indy network. Well, maybe you do not communicate with the Indy network at all. You would also need to include Anon Credits, the logic related to the Anon Credits credential format while you might not use that because you are just focusing on the W3C JSON-LD format. So yeah, you're basically pulling in a lot of codes. You're making your package a lot bigger than this necessary. And this is, yeah, that was not something we wanted to continue with. Next slide, please. Yeah, and so, and this is not an effort that is totally or not even mostly done by us, but the Aries community, they chose to basically introduce three new components, Aries Oscar, Indy VDR and Anon Credits, and these three components together can be used basically as a replacement for the Indy SDK. So they each take care of a subset of what the Indy SDK is to do. Now there are some other differences there, which I'm not gonna go into because that is beyond scope of this presentation. But so we have a new component that is Indy Oscar, which takes care of storage and photography. Then we have Indy VDR, which is the VDR is verifiable data registry. So it's really the component that takes care of the ledger communication. And we have the Anon Credits package, which is, again, it's the standard itself, the credential format itself. So it's a package that takes care of everything surrounding that. And this slide, Ariel is going to present. Ariel, are you there? Yeah, yeah, no problem, yeah, yeah. So yeah, in this slide, we are doing an overview of what's on the framework score. How are we going to build an equivalent agent an equivalent agent with zero four zero, considering all these new modules that Karim mentioned, right? So if you look at the zero three zero, we will have in the core, the functionality related to Indy and ledger that has been moved out and extracted out and went to the Anon Credits and the Indy SDK library. So if you want to build an equivalent agent, I mean, with the exact same features, but with zero four zero, you will need to use in your project the core and also the Anon Credits, which is a module that adds the main functionality and the credential format and the interfaces for Anon Credits. And the Indy SDK, that provides the implementation that Karim mentioned before about the storage, the ledger connection and the cryptography. But we have also the option of creating an equivalent agent, but using all these new shared components. So in this case, we will need to use five different packages, the core, the Anon Credits, Anon Credits, RS, Ascar, Indy, VDR, what will be the difference between both actually, I would say that it will be better to use the new one, I mean the one on the right, because the new Anon Credits libraries are a bit faster, are more flexible, you can also support for other ledgers if you want. And you can, and especially because it also supports the fully support the new Anon Credits specification, something that we will talk a little bit later, right? By the way, if you look at the core, you will see that there are still a lot of sub modules, right? So you, we can see that we have the Bitcoin, Discover Features, Program Reports, and we can see that there are still a lot of sub modules, Program Reports, Out-of-Band, Routing, that are mostly related to did-come messaging. And maybe if we continue on this, with this philosophy of modularized AFC, we can in a near future extract them out as well. So if you want to build an agent that is not support, that will not need to support did-come at all, you can, of course, do that, right? So maybe we can go to the next slide. Yeah, this is a consequence of removing Indie SDK from the core. Previously, we had a default wallet, which was the one that came from Indie, but now in order to set up an agent, we will need to provide a wallet class and interface implementation, which will be done by the Ascar package, but there is room to also provide a different one. You can also implement your own wallet as long as it complies with the wallet interface that basically needs to implement some methods for opening a wallet, closing, did-come message packing if needed, key storage, and so on. And that give us the possibility of, in a near future, we hope to create a wallet, a peer-shared wallet that could allow us to easily run the AXA on a browser, which is something that I think most people from the community is expecting to have some someday, right? So we will talk about that later by the end of this session. So we can continue on the slides. Yeah, there are a few more differences. Also as a consequence of removing the dependency on unencredited Indie SDK was that previously, we had some properties on the Asian configuration, like this public DID seed on public DID, that was used mainly for Indie to create the objects in the ledger and that stuff. And now we are not using that anymore, but we provide a way of importing this that were created somewhere else. And to also support if we want, more than a public DID. This can be mostly interesting for those who are using AXA on the server side or in public entities. We can continue next slide. Yeah, and this is another feature that we added. This is not something related to the architecture, but it's something that we are using in our project. So I wanted to highlight it is that we can connect to, we can not only connect to other agents by using connection invitations or out of band invitations, which is the classic QR code that we, I mean, it's the classic invitation code that we render in a QR code, but also we can connect directly to a public DID. So this is what is called the implicit invitation. So you just put the DID and the agent will, and you set up, well, some stuff like the areas that you want to use and the handshake protocol. The agent will do all the work needed to create a connection with, to resolve that DID and create a connection to it. And also, and the same works from the other side. I mean, if you have a public DID, you will also receive the invitation, the connection request, and you can decide if you want to accept it and move forward. And that's it for this session. All right. So yeah. Yeah. So the next section about beyond areas as it's called. So as you might have seen in the beginning, somewhere in the components, we have started work for implementing protocols that are outside of the typical areas ecosystems. In other words, as I mentioned earlier, areas comprised of a set of various RFCs, but the space is evolving. Recently, this year, both the European Commission and the Department of Homeland Security have announced whether preferences or they have hinted on the standards they will start to adopt. Nothing is in stone yet, but they are looking at a certain set of standards and they are not all areas related. If we, on the right-hand side, you see an example of this is the ARF. It's short for the Architecture Reference Framework, which was published by the European Commission. And I hope it's big enough to read, but this diagram shows a few choices they have made. So for instance, the credential formats that they will use are MDoc, which is an ISO standard. For proximity flows, and W3C, Verifiable Credentials, and then the SDJWP variant of that for remote flows. That is for the credential format itself, but then we also have Exchange Protocols. So in the areas that we use, they've come mainly to, well, to come as a mechanism to issue credentials to present proof and to do a variety of other things as well. But the European Commission has chosen to focus on well, a bit at near where open ID for Verifiable Credentials stack. So on the top left, you can see that they for issuance of the Open ID for Verifiable Credential issuance protocol. And for the verification side of things, it is Open ID for Verifiable Presentations and SciO3 too. This is not, all these details don't really matter in the scope of this session, but I just wanted to point out that there is a lot of movement in the space and there are a lot of other protocols and other ecosystems that are becoming more prevalent. So we really feel that there is a lot of value in adopting support for other standards outside the areas ecosystem. For one, it enables a broader range of projects that can be used in. The second point is a little bit cut off, so forgive me for that, but what I was intended to say there is that it measures the relevance outside of, well, yeah, let's say geographic areas where Aries is the choice. I know that Canada, for instance, really goes for Anacrets, for instance, but again, in the EU, other choices are being made, so extending the support to other ecosystems makes it relevant also, for instance, for in Europe. But all this modularization and adopting other standards, it really forces us to rethink architecture and a result of that is that it also ensures more longevity and it makes it more extensible. We have had to define a lot of interfaces which in the end, if other protocols come around, makes it just these architectural changes that we're working on right now, it's ongoing, but they ensure that it will be easier to add other standards later on as well if they become more relevant. And an interesting feature of this is, and one is already possible, is it could and how feasible that is is, I don't wanna make a judgment about that, but it could facilitate interoperability between different ecosystems and stacks, et cetera. So an example of that is, which you could do now, I have not done it yet, but in theory, you could get a credential issued over OpenID for a verifiable credential issuance and then present proof that credential over.com. So that's an interesting bridging thing that it can potentially also bring next one. Yeah, so in other words, we envision, although it's every spring with JavaScript, it's a bit weird and it feels a bit weird to us, to ourselves as well, but we really think that every spring with JavaScript is like a sort of all purpose, such sort of an identity toolkit is the most valuable. There are a lot of different islands in this exercise space, but having a toolkit or a framework that can act as a bridge between all of those is really valuable, I think. The Swiss Army Knife. The Swiss Army Knife, that was the first blog. Exactly. So yeah, we are going to talk a little bit more about the, or more in details, about the lecture agnostic and on crates, which is not something religious, but it's about how these, how the indie credential format was evolved, especially last year when they became a standalone project, because the community saw that there was a lot of value in the on crates specification and format, let's say, because of the unique properties that has this kind of format, but the issue for implementers was that it was highly tied to the indie lecture, which was, I think it was a little bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of the lecture, which was something that was not very appropriate for every case. So the community started this standalone project where the idea was to standardize the specification because at that moment it was just part of the indie SDK code and almost nothing was formally established and specified. So this working group has written the on crates specification V1 that was compatible with what has been done in indie, but there were a few tweaks to make it fully compatible with any kind of verifiable data registry besides indie, indie, right? So, and this working group has also developed an implementation in RAST based on the shell components that Karim mentioned in the beginning of this presentation that's called an on crates RS, which has some wrappers for Python and JavaScript. And of course, we have implemented our package on base on these wrappers. Actually, we developed the wrappers, but that's another story. I will say that, I can probably say that AFC fully supports this on crates specification. Sorry, there are some people from a KAPI community, but as far as I know, AFC is the only framework that fully supports these new libraries. But I put this star there in the fully because we don't have official support yet for revocable, for issuing revocable credentials. We can verify revocable credentials, but we cannot issue yet, but there is an ongoing PR, so it will be soon available. So we can, by the way, we support both the new on on crates and also the legacy in the credentials. We can go on. So I will talk a little bit about how these on on crates modules are architected. So the idea is that we have a generic module that defines the basic API for on crates, which allows us to create objects like the credential definitions, schemas to get from any BDR, all those kind of objects. And also defines the format, how the objects are format. And the interface is that the implementation have to implement to create the bindings with the actual crypto libraries that are actually doing the work of doing the cryptography, the aesthetic cryptography, and also to connecting to the appropriate lectures to get and create the objects. So the idea is that we have for an agent to work, there should be a module that implements these services for holder, for issuer, for verifier. And at least one module that adds are what we call the registry, which is actually, it's an interface to the actual, to a given video. So the idea is that we can register one or more registries in order to support one or more lectures. It's something analogous to what we have in the DITS. We can support different DITS methods, but we can register different resolvers and registers. And in this case, we can support different kind of BDRs. So we need to add some more registry. So in this case, we are mentioning the Indian non-cred registry, which is implemented by the Indie SDK package, and also in the Indie VDR, and the checked non-cred registry that also is implemented by another module, which is the check V SDK, that we will talk a little bit more later. We can continue, move forward. Somebody is asking me if I speak Spanish. Yes, I speak Spanish as you can see from my accent. So, well, basically we support in the main repo we have support for the classic, let's say the classic VDR, which is the Indie. So we support the Indie method for non-creds which works with both legacy and Indie DITS, and also with the new Indie method. And the checked, as I mentioned, that was contributed by the check DITS, which was a major contributor in all this stuff about making non-creds that's your agnostic. So, yeah, we can maybe continue a little bit more. So yeah, the idea is that if you want to add some more support for other VDR, it's quite simple. You just need to implement an Indie non-cred registry interface with the bindings for the VDR you are using. And if needed, because each non-cred registry is registered to a particular DIT method, you will need to implement the DIT resolver and the registry and add them to the DITS model, right? So there are a few methods already supported or in development and the development by the community, which are the Cardano made by RootsID and the DIT web support that we are using, which allows to store and manage non-creds without the need of using any blockchain at all. So we can put them directly in any web server and just use the non-creds library. So for instance, in our case, in our application, we are not using Indie VDR. We are just using non-creds arrays. We are using the core and these bindings for the web. We can move forward for the demo. But in time. Yes, thank you, Ariel. So I think everything what they just said sounds very cool, but we have to see it in action, of course. So first I will do a short demo using a wallet that we created at Animo. It is built for a Dutch project, which tries to create a minimal set of requirements as like a subset of the ARF, what Karim just mentioned. So the ARF still leaves some like holes in their first implementation or document. And we decided to fill in those gaps, make some decisions and then we created a wallet for it together with other companies who also contributed to the project and I will give a quick demo of this wallet right now. Let's see, yeah, it should be here. So here we have a very simple login page for the Dutch Blockchain Coalition and we can log in with our wallet switches on the left side. I think we can give some links to the wallet so you can play around with it yourself. But basically this leverages the open ID for VC specifications. So we use open ID for VCI for credential issuance, Cyope and open ID for VP to present these credentials. And this is just a very nice, simple login flow. Again, very demo environment. So no additional security is provided. Here we can request a credential. So I'll just, upside this, not mobile friendly. I will fill in my information here, email and then I will click share. And then we can see the two wallets that are available, which is paradigm from us and the Serial Wallet, which also does the open ID stack but with a bit more functionality as well. Here we see a QR code, hopefully I'm the first one to scan this. And here we can see the credential. We also have a little display here, which is all from the W3C JSON LD specifications that we get this. And this is the content of the credential, which we can accept. And now I have three attendance credentials, which might be a bit much, but it's a demo. And then we can go back and use this QR code to login, which basically does a proof request of the credential, which we can see here. We want the first name, the email and ID, last name and the event. And if I click accept, it will share it. And I am logged in right now, which can be seen here. So, yeah, I can see here I am logged out again very, very much demo environment, fun to play around with. But it shows the specific demo quite shows very well that the open ID for VCI group of specifications is very, very simple. It builds on top of a lot of standards that already exist. And yeah, it removes quite some overhead to issue credentials more quickly. And I'll show you that right now. So if I go to the slides, from a holder perspective, this is basically all the code that you need, basically with a massive S-tricks because of course you're set up with state management and everything, we're not gonna go into that. So we can set up an agent and we add a new module called the open ID for VC client module. This is specifically for the wallet sites, which in open ID for VC terms is the client. And we also need a wallet here, but it's all left out so we can make a nice little example and we're not throwing a lot of unknown modules at you. And right here below, we initialize the agent quickly and then we call the methods request credentials using three authorized code. So with the open ID for VC specifications, you have a preauthorized code flow and a authorized code flow. For this demo, we rely on the preauthorized code flow. Here we just pass in the data which we scanned. As the issuer, you're right. We given a couple of additional fields. Also the proof of possession verification method resolver. We love our long names. It's left out to keep it a bit shorter, but here you would basically go to a verification method in your document, which will then be used to sign the credential using that verification method. But that's all nice. It's a nice demo, looks all cool, but I think a lot of people here are actual developers. So it would be good to also go to some real code. In this demo, which is available at this link, we will actually use Ditcom and Anokratz and we will establish a connection with between a holder and an issuer using the INE SDK. Then we receive or we register a DID for the issuer. Then we register a schema and credential definition. Afterwards, we offer a credential from the issuer using the new Anokratz model. Once that is received by the holder, we actually migrate the holder to the new shared components. The underlying database structure for INE is quite a bit different than for Oscars. So we wrote a custom migration script, which I think we'll touch upon more later, but the gist of it is so you can reuse your INE SDK agents credentials and everything that is stored in there with the new shared components. Then afterwards, at the last step, we present a credential to a verifier with the newly migrated agents to show that everything still works as it's supposed to be. I'll just slide to the code, which is open right here. I hope it's big enough. I can make it bigger if it's big enough for some people. So we'll just quickly go through the code and see what it's doing. Again, repo is available afterwards. So if you have any questions about how some part of it is done. Over the shared. Perfect. You can look at it there or ask it in the Q&A after. We have some time for questions. So first, very simple. We initialize an agent, which is the holder using the INE SDK. We can quickly look here to see all those modules that we talked about. We have to go a bit up, sorry. This is for the INE SDK. So here we register the INE SDK as our wallet. We register Anacred's module and we use the IndyFDR Anacred's registry to resolve the Anacred's objects. And here we have the Anacred's RS module, which is a module around the Anacred's JavaScript wrapper, which is, for Node.js, it uses just your FFI bindings and for React Native it uses certain modules. For DITS, we only need in the DITS resolver as the holder. And for the IndyFDR, we supply a network, which is the PC over in test network, which is just a simple Genesis transaction and some information, like if it's a production network, what is the name space and whether we should connect to it on startup. For connections, we supply the module again. It is provided by default, but if you want to modify the configuration, you have to supply the module again with the new configuration. So here we want auto accept connections to true, which basically means that if we want to establish a connection, we don't have to go through the entire process manually for multiple steps. Most of the time users just want a single like accept or decline and it helps a lot with that. Below we have the credentials module. Same configuration as for the connections, we can auto accept credentials. This uses always, which is strongly not recommended to do in a production environment, but works very well for demos. This is the same as auto accept connections. Basically every credential that comes into the agent, we just accept. Doesn't matter what the content is, if it's true or not, we just accept it. Works very well for demos, definitely not recommended for production environments. And below that we register some credential protocols, which is for now only the V1 protocol, which uses the Anocrates credential format service. And right here you would specify like a JSONLD credential format service or a legacy in the credential format service to support all of them. But for this we try to keep the modules as minimal as possible. So that's the holder. And we initialize it, and with initializing you just, you initialize the wallet, you set up the transports. I think people that are familiar with AFJ know exactly what it does, but it's just setting everything up for you. Right now, as some of you who might notice who migrated to zero for zero already, is you have to create a link secret now. The NDSK I think put that under the hood. Now we have to do it manually as a user. I think there is a pull request open to also automatically do this for you. So this step will probably be just a configuration option, but very simple here. We just call trade link secret on the Anocrates module and we're done. Below that we initialize the issuer. I'll just go over the issuer modules and then the rest of the modules I think we can skip because most of the time it's the same stuff. But here we can see we actually register SCAR, Anocrates, Anocrates-Arrest, again, it's any VDR connections and credentials. Most notably here is a SCAR instead of the NDSK. Again, the new crypto and storage implementation which is required if we don't use the NDSK. We have in our disk module, we also have a registrar because we are an issuer and we have to register our DIT. We can also import it what Ariel mentioned. So you don't really have, you don't need a registrar, but for this we don't import it. So we have to register it ourselves. Network, again, BC over in test network and the rest is all the same. So below we actually get to some functionality which is creating and registering a DIT Indie. Codes for this is fairly simple. If this is a test network, so feel free to copy this seat, it's all fine. Basically what we do here is BC over in as like a web UI where you can create a DIT. And then right here we copy the seat that we use there. This is the DIT that came out. So we also put it here. This would be fully qualified DIT which is also something we did from 0302040 as we moved to qualified identifiers for Indie. And here we have the import function which basically sets all of this up. It might look a bit weird that we use the safety private key. I had a discussion a while ago why this was the case. I forgot it, but I think it was required because this is just how the Indie SDK did it. And for Ascar we need to keep backwards compatibility. So this was done there as well. That's the seat is actually the private key. And we can register a schema, registering schema. Nothing new actually in 040 it's still the same as we had since 010. So we just register a schema with the same attributes as always. We have a name, date of birth, email and occupation. We did change the interface a little bit so it now looks actually very familiar to the DITs interface, which returns a state. And if the state is filled then there are some error. And if it's not, then we can just return the schema ID which we can then use for the credential definition. Let's go there, credential definition. And again, yeah, everyone already familiar with this probably yelling right now, but here we simply just register the credential definition with the schema. Same interface again, nice and consistent. If you don't want interface, you know them all. And here we just return it. And right here we actually establish a connection between the issuer and the Indie SDK holder. Not gonna go in depth in there because yeah, that nothing really changed there. We just create a connection in there if you want to see the code. It is in the repository. But right here we have something new which is offering an Anocrates credential. So right here will be the API for it. We have an issuer and we have the credentials module and we do offer credential. We use P2, we send it with the associated collection ID and these are the attributes that we want to issue. And also the cringe definition ID, which is required. A simple utility method here to basically wait until the holder has the wallet. And then we shut down the Indie SDK wallets. After that, we migrate it. So this is what I meant before with we use an Indie SDK agent and every wallet that is currently deployed with AFJ uses Indie SDK and with this very, very short script you can migrate your Indie SDK wallets to the new Anocrates structure. You just have to know the database path which is figuring out which path that this is all provided in the documentation. So it should be a relatively straightforward migration. So we go back. Then here we can initialize the shared components holder and we also initialize a verifier. Then we create another connection between the verifier and the holder. Here we request an Anocrates proof using this. So again, the connection ID and here we basically create an Anocrates specific request. So if in your configuration you add something like, I think for JSON-LD a keyboard display here without a completion and you can do JSON-LD and then you can provide the request for a JSON-LD credential. It's very simple. And then here we just wait until the credential is or the proof is presented and the verifier agrees with it. So let's run the code. I think I can go here and then we can just simply run yarn start and it'll go through the code. If you try to run this after a workshop every single step requires an enterprise so we can go through it. So I'll just press enter. It's initializing the holder, creating the link secrets, initializing the issuer. Now it's gonna register the objects that we talked about. So here we registered a bit indie and then we registered a schema with the full new qualified identifier and the credential definition always takes some time but there it is. I think if you go to the test network you can see these objects now in the web interface. And now it creates a connection between the issuer and the holder. Then we offer the credential and it's accepted by the holder which is again all automatic. Don't really have to do any steps in between which is extremely nice for just quickly developing something then we're shutting down the holder and now we're gonna migrate it to the new share of components. So all the indie credentials are moved into the new structure, the keys are moved, everything that you would need as a holder or a mediator. Again, more on that later on. Then we initialize the holder with the share components, initialize the verifier, all very simple. Create the connection and now the proof is requested and here we can see that the proof was presented and this is what we shared with the verifier as the holder. So all of this is now quite simply possible with the new zero for zero release. And I can go back to the presentation. Let's see. Now I think Kareem will tell us something about our beautiful new documentation. Well, it's not that new anymore but I did want to mention it because we have updated it significantly. Can you give us an example? So in the last, for those who were there in the last presentation, I think about a year ago about the zero three zero release, that was, I think when we first introduced the documentation website. So if you go to this, I'll enter the chats where we can follow along. Aries.js.org. Yep, there it is. And then we introduced that documentation website was very, very minimal back then and it's still sadly, not everything has been documented but I think we, yeah, we're getting somewhere. And the first thing I want to point out is that we have version documentation. So if you are still, we didn't replace everything with the zero four zero docs. So if you are still looking for documentation docs, so if you are still working in zero three zero, that is no problem. We will obviously advise you to upgrade and to migrate at some point. But the, well, the previous documentation that was previously there is still there. So that you can see here in the image in the right, the top right corner can choose for a different version. And additionally, well, Aaron has talked about this quite extensively and I'm showing all kinds of examples here that we have and we already had that previously from zero one zero two zero two zero from zero two zero two zero three zero and now also from zero three zero two zero four zero migration guides. So the API is changed here and there. The script that we're in just showed you was really about the storage. So the models or the objects that are stored they are slightly different in terms of, yeah, in terms of data structure. So there needs to be some migration there for that you can use the scripts. But these migration documentation or pages here they are really like, what we have the zero three zero API versus the zero four zero API and how to migrate. Basically what the lines of codes, what the lines of codes do you need to change? How do you need to change them? So we really try to guide you through that there. And yeah, lastly, what I wanted to point out about the documentation, which I think is quite cool is we have these beautiful little tabs here. As you can see in the middle. So we have an indie and I'm a great step. For instance, there, this is just one example. There are many, which basically tells you, okay, if you're still using an industry, then this is how you should call this function. But if you are using unencrypts, then you can use, well, then the function calls should look like this. I think we can move on. That was about the documentation. Yeah. Then I think it is time to talk about the roadmap. Yeah, it's time. And there is gonna, oh, no, this is Ariel's slide. Service side, I have J. Sorry, I was writing on the chat. That's okay. So yeah, actually we are already supporting server side actually in our, in both animal and us are using quite extensively the AFC for the backends. But this is something that we will want to focus on in the incoming releases. So that's why we wanted to put it here, right? But something that we want to say was that even if AFC is mostly known for mobile environments or the holder side, we believe that we think that it's worth mentioning that AFC supports almost all the features needed to create an agent that can work for using other roles like mediators because we do support, we fully support both mediation coordination protocol and also the message pickup V1 and V2. We have a very basic message queue in our default implementation, but we can plug in something more sophisticated like storing that in a Redis or in Postgre, we can add push notifications. So we have the tools to make an AFC mediator to work or to build a basis of a mediator that is compatible with all the protocols that are defined for that. And same for the credential issuance because we usually use AFC for holder and very fire roles, but we can also issue credentials in various formats. In the case of the unknown credits, it's true that we don't currently support revocable credentials, but we are very close to that. So maybe in a few weeks or so, we have the PR merge. So in the next minor version, we will support it. We can continue the next slide. Some reasons for that. Okay, this is mainly our reasons for choosing AFC because we have a very small team. You know that it's hard to find skilled developers nowadays. So we wanted to share as much as we could of the code base. So the good thing about using AFC for both types is that we don't have to master two different languages. This is not only a problem when you are dealing with high level code, but also if you need to adapt a low level library because you will need to also create wrappers and you know that it's not very straightforward sometimes to create them. So if we can make the whole team to work on the same environment with the same tools, it will be usually faster, especially in small teams. And also the other reason is that we wanted to create custom features, I mean, custom protocols. For instance, in our project, we are using Bitcoin for chat. So we have created some protocols to send media to other parties, profile pictures and that stuff. So for us was a lot easier if we just made a single extension for AFC and instead of having to create two extensions for, I mean, one for the server side and another for the client side. And also some other nice features of AFC, are the storage backend flexibility is true that at the moment we are a little bit tied to the, I mean, we have only the implementation of AFC as an alternative to ING-SCK, but our goal in the short term, we only midterm, let's say, would be to make it more, not only lecture agnostic, but also database backend agnostic in a way that we can adapt it to use as mentioned in the beginning of this conversation to use a browser or whatever. So, and also something that Karim already answered in the chat is that we do have an extension in the Aries Framework Shavascript text repo that provides a REST interface. So you can easily set up an agent with a REST API. So that's some of the good things about using AFJ on the server side. And that's it. So one question that I think I got from the beginning when I started to work on AFJ was, when will we have web wallets? Which is a very good question. I think web wallets, they serve a very nice purpose. And for me, it's always, I think always demos came to mind, like just a quick demo, you don't need to host a server for it. It's very simple. And with what we talked about with modularizing the framework, we basically every module we separate, we get closer to full web support because right now the main issue is with the framework is we just have too many dependencies on node-specific items or reignitive-specific libraries. And they are just not provided for the web. Before that, with the in the SDK, there was just no like web replacement for the entire in the SDK. So we had to find alternatives for that. Separating everything out into their own module makes it a lot easier and more manageable to replace smaller parts with a browser implementation. For example, for a demo, you can probably create an implementation of Ascar for AFJ with using local storage and browser crypto. I think that that would be relatively manageable. There is also of course a web assembly which could use Wasi as a for storage. This is of course more of like a full, like actual web wallets and not just a demo environment, like you wouldn't use local storage to store your credentials, but Wasi could actually provide a way to store credentials on your local device and access them from the browser. Packages like Anacrets are compilable to web assembly as well. So that's something we can also take a look at in the future. And in the VDR, I think as well, but the re-implementation of that for what we need wouldn't be, it would be a lot less effort than re-implementing the in the SDK. So browser support is definitely on our roadmap in the back of our mind, like as long as core remains platform agnostic, we can create modules for everything that we need. And then we can slowly move to a first day demo environment for AFJ where you can just have a local credential and you can just be a holder in the browser. And afterwards we can move into more serious actual production implementations, for example, with Wasi or with decentralized web nodes, which would be a great thing to add to AFJ to support secure storage like that. So AFJ also really aims to support at least the required fields of the architecture reference framework, which is the European documents that Karim mentioned before. We are relatively far with that. We have quite some basic setup for that. So, you know, storage also, you always need storage, but there are still some items that we miss. So for example, the first one is JWT credentials with select disclosure. This is something that Karim and I actually have been working on for a bit to add it to AFJ. So this is something that might already be there in the 04.1 release. Then there is ISO 183, which is the MDL and MSO object group of specifications. This is mainly required for the proximity flow. So share your credentials over NFC and Bluetooth. This is something we would love to add to AFJ, but it's just not something that we have a lot of experience in. So we're sort of waiting for a TypeScript implementation for this that we can reuse in our framework. And parties are working on that. So we would love to have this before a 050 release. And to be more compliant, we would also need to support basically all the open ID for VC protocols. So my issuance and presentation. The demo that I just showed you with the wallet that had all those items, but right now they're not inside AFJ yet, mainly because we had to do it a bit quicker and we didn't want to think about all the architectural things that we're doing for this project, but they will be backboarded into AFJ to fully support the open ID for VC stack, which is a very nice thing to optionally add to your agent. And the last item is the ARF mentions. I think it's required that all wallets that are compliant need a secure enclave or hardware support or hardware security module or I think Android called it shared secure storage or something, I forgot. But you basically need hardware-bound crypto, which is extremely interesting and like something we definitely also would like to add. We don't have a clear way to do this yet but it's definitely something we're looking forward to for other parties to help us with or for us to implement. And also like even outside of the ARF, this is just a massive benefit to storage if you don't have to deal with exposing your keys in memory and being vulnerable to all kinds of attacks with that. I think maybe Karim has something to add to this. No, no, I want to add, like we are pretty far indeed, like the demo baron previously demoed or gave shows that not only the open ID for archival credential issuance, that is currently included in the zero for zero release as well. But the verification protocols are not yet, but as Birin showed you, in the demo it works, so there's ongoing work into doing for implementing that as well as SDJOT or well, the SDJWT credential formats, we've been working on that and indeed we think that that will be added to probably the zero for one release already. Yes. Yeah, so one other thing, what we found out when you remove everything from the core is that setting up your agent becomes quite a big chore. We first, we just provided some configuration and some notes or reignited specific dependencies and now you have to provide all these modules and you have to know which one you want to use and it can get quite complex and we've definitely seen some get up issues from that already. So this is something that we know is a problem and that we are working on. Some of that work would include reworking your wallet a bit. I think this is mainly about separating the crypto from the storage, but Ariel might be able to fill in the end if I missed something. We also would like to make the core a lot smaller. Right now there is still a lot of items in the core, very, it comes specific and just some things that we would like the user to be able to provide instead of the core providing it to you. Not all use cases need everything and we want, especially when working with like native libraries, we want your app to be as small as possible and not everyone needs an IndieVDR or not everyone needs the Indie SDK for storage when Ascar or your own implementation of React Native MMKV also suffices. So making the core smaller would make the app, in our opinion, a lot better because it makes it smaller. And the last point, which is something that I think is very important to making AOJ a lot more starter and beginner friendly for people that just go into the space is to create pre-configured agents configurations, which is a nice sentence. So basically here we would say like, okay, a very common use case is DidConfit2, AnonKratz, IndieVDR, Ascar Yeah, maybe some configuration for your connections or a mediator or something. So we can create packages that would just contain that and then you could plug it in and then your agent setup would be back to just one line of code. For example, also think of like an ARF agent that would be compliant. So you just import one line and the agent that you're using is fully ARF compliant or whatever interop profile may be defined. So an AIP1 agent, an AIP2 agent, something that we could have. Yep. Yeah, and also the DidCon support. You can, we can also pre-configured agent. At the moment, I don't know if, I think nobody asked, but we are also pretty close to support as DidConfit2 in AFC. This is one of our priorities for the next major release. So the idea is that we will support both DidConfit1 and V2 initially by using Ascar as a backend for that. All right. Well, this was a brief overview of, well, was it brief? No, it was not brief at all. It was 80 minutes. This was an 80 minutes overview of the 040 release. There are a lot of questions in chat. Some have been answered, some haven't. So the rest of the time is really up to questions. So, John, I don't know if you want to lead that or... I'm happy to. We've been, as the presenters, you, Kareem, Ariel and Baron have been fantastic about answering questions in progress. So we can probably get in some more questions now. Denver, I did want to make a point. You just asked about the meetings. So those are community calls every Thursday. They're not like a presentation, like what the team put on today, but also we have the asynchronous discussions that happen in Discord. We have other workshops and I'm going to put a link to that right now in chat workshops for Non-Cred's Steven Coran who was on the call a few minutes ago. He's gone now. Steven Coran did a fantastic workshop on Non-Cred's and we have some previous workshops on Indian Aries that are hands-on. Jorge asked, will AFJ support adding new DITCOM protocols once DITCOM V2 support is added? Yes, definitely. So I mean, it is right now, that is also possible, right? So I mean, we have DITCOM, it's currently still part of the core. So you can see DITCOM has two, or yeah, it has two, I guess, different facets. You have the actual DITCOM core logic, right? And then you have protocols that are built on top of that. And let me quickly find how to go back all these slides. Is that easily done here? So as you can see here, some, and I think that is the plan to do in the coming months is for instance, these here, these to the action menu and the question and answer protocols, those are both DITCOM protocols, they are defined as separate modules because you don't think it is, not everyone needs those, right? Not everyone needs DITCOM as a whole, especially now with the introduction of OpenID for VCI and well, OpenID for fair file credentials as a whole. You might not want to include DITCOM. So the plan is to move DITCOM out of the core as well. So it is basically an optional dependency you can include or not. And then with a separate DITCOM module, you'd be able to define other modules that basically extend or build on top of that DITCOM module. So definitely. Cool. And DITCOM is the reason why I got involved and decentralized identity to begin with. So I love it. I love DITCOM. All I want to do is make, is never have to use LinkedIn again. Thanks to DITCOM. Someone just asked. Yes. Does an on creds package support any missed approved crypto? This is an AFJ call and Steven has left. Can anybody answer that question? So I think this, the very short answer is no. We use RSA based sales signatures. I think Steven or Mike, probably, or Andrew can give away the answer on this. But yeah, the answer is no. I think there are looking for FITU for PS signatures, which might be ES256 based, but I'm making a very big assumption there. I haven't looked at the specification for that. But I do know that FITU is looking to broaden their crypto suite. Cool. Viet asked, can we revoke credentials? Yes. I think that that question was actually answered a few times. Yeah, we're very cute to LinkedIn again. Yeah. For an on creds, that is true in a sense that I think we're still working on the issue inside of that, but at least you can, so no, I would say, because the issuer is the one that revokes. Yeah, that's exactly so. Yeah, that's much yet supported, but you can prove that your credential hasn't been revoked yet as a holder for, because revoke, I mean, yeah, different flavors, if you will, of revocation. So for W3C, you also have the status list 2020. One, two, I don't remember. That is not yet supported, but that will. Yeah, but the PR is almost finished supporting that. So at least an initial support, I think will be there very soon in a few weeks so I guess when Timo comes back from his vacations. Then everything will be done. I'm gonna tell Timo, he said that. Do an on creds have any way to add NIST approved key types? I think that's the same question, right, or? Well, the last one was about revocation, but this is about NIST approved key types and that is AJ had asked that. But the one before that? Oh, maybe. I think there was one about NIST. I'm going in reverse and I'm getting lost. Okay, cool. Was there any consideration to use the FIDO standard to store and manage keys on a mobile device? Not that I know of. I am personally also not too familiar. I've looked into it a while ago, years ago, but no, not that I know of, but maybe someone else can comment to this because I'm not at every working group. Anybody wanna comment on that one? I think if you really want a correct answer for that, I think opening an issue at Escar would be the best because basically if Escar supports it, then we support it. But I'm also not 100% sure. No worries. Nile just asked following up on an earlier thread. So the non-creds and NDVDR modules aren't necessary in ND SDK, for example. And then I'm sorry, I just noticed Ariel replied. All right, great. And then there's a GitHub link, okay. Denver asked, in terms of setup, there are quite a number of issues for yarn install on Windows for Node version 16 and 18. Are those being recognized and is it affecting anyone else in terms of the demo running? Oh, that's answered. Yeah, but that's something that maybe it's important to clarify for because there was a, there were lots of questions about that in the last few months is that we do have in the Node.js environment, we do have some problems with Node versions below 18. So we support, we will say that we support Node 18 onwards. So because there is an issue on the JavaScript wrappers that prevents the shared components to work with the performance they should. So to make it short, you will need to use Node 18 to properly run the Node.js environment. Node 18 to properly use AFC on Node.js. Okay. Can you explain a bit about unrevealed attribute support in 0.4.0? So, yeah, I read that question. I do not completely understand it. I guess this is hinting to, sorry, to select a disclosure, but I'm gonna pass this to Barron because he just nodded me that he knows how to have it. Cool. Yeah, so I assume it's about select disclosure and CQP's. So nothing really changed between 0.3.0 and 0.4.0. We still support all the Anacrets, zero knowledge proof way. So we predicates, selected disclosure, all of that is still in there. For JSON-LD issuance or verification, I think we don't yet, but that's mainly because of presentation, present proof V2 support. But we do support the underlying crypto to select the disclosure with JSON-LD. That's what it's called. Any plan to support a better runtime? I'm sorry, Trion, I stole your role. No, take it, go. Yeah, at one point I tried to create a demo wrapper for the NESTK, which was sort of working, but then we all moved to the shared component, so I left that work. I think it's definitely doable that now provides a, if I interface by default or a way to do that, and no, it doesn't really. So I think that would definitely be something cool. And also, yeah, definitely something we're open for for contributions. I think we can get some pointers and it would just be like SCAR and NFDR and Anocrats. Yeah, I'm gonna get it back to you, Sean. Yeah, and if you'd like to contribute, please check out the Aries JavaScript channel on Discord and the meeting that the Aries JavaScript community has every Thursday. I'm gonna repost the links for this session in a second just so everybody's got it. Someone asked. Have Yaqou, Yaqou, our father, Yaqou. We already know the answer, so we, come on, you're ruining the presentation now. Deno question, I have a question from Denver from earlier, nope, somebody just answered that. Will it be, is the last open question that I can find, will it be possible to have more frequent meetups? Nope, yes, we are, every week he meets. And that it's less of like a demonstration and a presentation like today, Denver, but the team is definitely meeting and they're always having conversations on Discord. And we are also, to jump in, we are also like, the new features are being done out there, right? So if someone worked on a PR or something that gets in, then they demo it, yep. I'm out of old questions or, so I've been basically, if a question has been answered in the chat, I'm not announcing it again. I think that's it, anybody else have a comment? Yeah, we have a question from Yaqou about the, if we suggest to migrate from, 030 within the SDK to 040 within the SDK or go directly through the shared components, I will suggest to move directly to the shared components. I don't know what the other guys say about that. No, but can you, because I think the question was about scripts or not, like, how do you suggest? Yes, it depends, in the, yeah, if you are using, the migration works only for, on the mobile side, right, on SQLite. Yeah, so it's only mobile, so specifically for the Inusdk to Escar. It's only mobile SQLite. So only mobile-ish. We also have support for mediators, because basically we currently don't support migrating the schema and the credential definition. So a holder or mediator would be perfectly fine to migrate with that. You can directly migrate from the Inusdk 030 to the shared components with 040, but there is a specific order in which you need to run the Escar migration script and the AFJ storage updater, which is all explained in the documentation from migrating to from 030 to 040 and also migrating from Inusdk to Escar. So the docs will probably give you everything, every bit of information you need. Are there any other questions for this team who've done such a great job with this presentation? All right, I would like to thank everybody for joining us today. And I would really like to thank the presenters, Ariel, Baron, and Kareem for doing such a great job of both going into detail on what's new in ARI 0.4.0 but also, you know, the how and the why and the wherefore how things work. It was really a great presentation and thank you. As I mentioned at the start, Hyperledger is powered by the contributors and maintainers who make all these projects work. We would love your contribution. We would love you to be involved. We'd love you to use the software. Check out the Discord and the GitHub and the Wiki for more information. I'm gonna put the links back in here again. Just a note, when we do a workshop like this, well, let me grab a copy. When we do a workshop like this, I generally, for folks who registered, I'll send out a thank you note. I'm going to put these links as well as a link to the Wiki page for this workshop in both the YouTube video, as well as in the thank you note in case you wanna share the video or share the deck with your colleagues or coworkers or project partners, whatever you're doing. So that's gonna go out probably, YouTube's gonna encode the video over the course of a half hour, 45 minutes and then I'll hopefully be able to get that out by either end of day today or first thing tomorrow morning. But I really like to thank everyone for attending but most importantly, thank you, Kareem. Thank you, Baron. Thank you, Ariel, for doing such a great job. Thank you, Sean. And thanks to everyone for coming as well. Thank you. Have a great day. Have a great day.