 Okay, so today we're going to be talking about credential representation with SSI. My name is Jorgejo. I work with the Kiva protocol team. I'm also a maintainer of the Ares Max project. We're going to be discussing about, you know, like why we need to have credential representation for SSI, a solution to have a basic universal approach to do this, so that we start like working on this every time we start a mobile agent. So let's jump right right in. This is an example of the physical cards that we are used to use. I'm sure we all have like a few instances of this. They have like a couple of pros, you know, they're like easy to share on the physical realm. It helps create a consistency to the use of brands. It has some cons. They're like, you know, easier to falsify than if we're using like a sovereign, but we already know that. The question is, you know, every time we jump to have a mobile agent, how can we have something like easy to use like right away? Something like this, right? This is a wallet that I growed last summer. You see, like each credential has its own branding. We don't have that easy to use. And especially like, we don't have a way to tell another agent, hey, I want you to render this credential that I just give you in a certain way. So it doesn't really feel like a real like digital supply in terms of branding to the physical thing. I want to propose a solution for that using SVG because SVG is portable. It's already easy to stabilize. It's also human readable. If you are like a designer and engineer, it's easy for you to play with with a design. And it's already backed by a lot of tools. All of the agents that you can and all of the runtries that you can think that you want to to deploy a already support SVG. How are we planning to do this? Let me show you an example here. This is like an example of an SVG, a lot of like a design information like colors you can see my name here. If we change this and we have a substitution strings, you can see how can we start like a having some sort of like common format that is going to be rendered on demand in our own wallet or someone else's wallet app. Here's like a more like a complete example. This is how something that a designer will do and engineer will kind of like substitute that text. And you can see, you know, it looks like a exactly like a like what a physical card would look like. And if we go back to that to that wallet that I mentioned before, you see, it just fits right, right. So now the question is, you know, like, what if you don't have time to do the branding, right? Like, like, is there something that could be a universal representation, even if you don't have design resources? Let's go ahead and define how that what characteristics that that thing may expose. Once I have something that is like industry-wide that anyone can support by default is ready to use. So you don't have to worry about like writing support for that. It will be already provided for you. It will be your support accessible accessibility from the very beginning. If someone has any disability, you know, like this should like a render in a way that you could like use the operating system resources there. And that has only one option for branding. Like if you want to add that, you should probably create a custom representation. And the main benefit of this is just reduce the time where I spend in every time we create a credential. We try to solve a use case. And we're going to do this from scratch. This is like a basic example of what we're thinking here. You know, like something that can tell you where where the credential was issued, the amount of field it has, and it shows a selection of these of those fields. Now, how do we plan to like to bring this to the community? We want to follow a library first approach, meaning that we want the representation to be like a field that is easy to transfer as part of a connection that is easy to fetch from a centralized authority. If we go that way, and more important, we want it to be like very light in the code. Like for example, here, this is like on the example of a summary map. This is what's one one component that has the credential property and a template property. And you can see here that, you know, like we can actually support a web app even even for like a verification as well. So there are also far on the next step. So before I jump to comment like what to find this on GitHub, let me tell you a little bit about kind of like how this became a thing. So somewhere in 2020, we are here, we're implementing our first mobile agents, like we stumble upon this, like we were given a lot of design with several credentials and we're like, okay, you know, the best way to do this to create something more like a format. Then we hosted a panel in IW and we confirmed a basic of use cases. We kind of like a pinpoint like some ideas about how to approach, like kind of like start with distribution of this for a mobile agent support. The result of that is the presentation today. One week from now, we're going to be publishing the first Nougat package for this and that's going to be followed with a React Native package. And I mentioned here the projects that we're going to be using to kind of like demo this. The first one is the Aries Max projects. The second one is the Bifol agent. It's based on React Native. So I cannot hear any of the attendees. Now, I think that's by design. If you go to this URL, you're going to see kind of like a placeholder reading me. If you want to be part of using this from the very beginning, I would love to tag to you. If you could create an issue and drop your contact or like, you know, like showing like some problems that you have around this, I will be reaching out to you soon. So thank you for that. So if we have a moderator there that can provide some context, like how do we jump to the Q&A? Okay. So usually one of the questions that I get here is how to, yeah, the first question that I got on IW here was how to have, I mean, like how to share this definition among different agents. I think right now the main use case is to provide for the case of, you know, a specific use case that people need to deal with their own credentials, right? That's something that we have covered with this example that we show the next step would be to discuss with a few people in the community, like the best way to do this in a way that it also remains true to the principles of SSI. Like for example, we have thought about like kind of like a decentralized certification authority where people like propose, kind of like certify. This is like the default design for this specific type of credential. And then each agent will have some sort of logic to fetch this. And of course, if you don't have a specific, I mean, let's let's say that you can reach that definition, you could always rely. Yeah, yes. So Francesco does the library add up to different credential schema. So you can think of the, okay, yeah. So, so you can, so you can think of this process, right? As, as basically merging an SBG with the metadata of a credential with that info. So it's going to adapt to, you know, like to whatever credential you have there. Create an interactive card. I think this is, this is pretty interesting, especially for the default representation. Like if you saw kind of like that default design, let me, let me show it here again. Yeah, like you can see here that we don't have like that much space to show more than three fields. This is, this is something that we could definitely tackle with like, also a default interaction there, especially on, if you're like on the phone, if you could just like scroll like some sort of a gesture there, the way I see this happening is just provide a couple of kind of like access point that the developer of the mobile agent can expose. Like for example, let's say that you are just implementing a very fire kiosk, right? People are not going to be touching your screen, but you can like trigger that kind of, that a carousel effect with the credential. So yeah. Yeah, and also down here regarding the interactive card, the idea of this is kind of like create a kind of like the beginning of, of reducing for good the forking of like this, this process of like creating like new credentials UI, just have something that people can kind of like play with that share back to the community. And then we could just kind of like pre-apply this process of like, oh, let's find like the good ideas, put it in a way that is easy to mix and match and then rinse and repeat this. My, my guessing is that Elizabeth in my first experience building a wallet, it took me like a whole week to set this up in a way that was stable. So I'm guessing like if we could remove that time from every SSI project, that would be a huge boost in productivity. Another, another question that I get asked here is about the accessibility. I think this is, this is a, this is where it's nice that you're having kind of like a centralized package, because then we could like a kind of like a use all the power of the community to provide a very good support. So when you drop your, the component in an Android, right, is, it's just, it's just going to render with the necessary notations there. And then once we have like a one implementation, right, it's easy to just, to copy that and just worry about like your kind of like the specific use case of the new platform. Any other questions? Oh, yeah, yeah. So the library, like the first Nougat library is going to be released next Monday. And then I'm going to be working on the, on the React native package, because this is like a SVG in between those. It's likely we will get a something in for HTML, like a, like a React component. Yes, Paul says, so Paul is asking, should cool a universal rendering be standardized in the context of areas, etc. Yes. I think we should, I think we could do it. I think this is like the first step to that, like show the example on them, you know, make sure that we standardize this in the spirit of SSI. We don't want to kind of like over centralize this to help our this, our decentralized use cases. But yeah. Yacomo is asking how to ensure the SVG should be rectangles. Well, I think the, the design of the SVG is responsibility of the, of the person implementing the credential. It should be the self, so their self interest that this is going to render, to render well, because this is a thought about a card, right? We should, we likely are going to have some sort of like a basic checkings when you are like in developer mode, so that you could see a, like, let's say, for example, if the final SVG doesn't satisfy the minimum size. Yes. Yeah. So, so, so for example, let's say that the final, that the final SVG is pretty small, right? That's something that we want to show a warning in developer time, because, you know, if you want to do a custom representation, that is more like a little space. This is just like for the listing. This is the, the idea for this is to make it easy for you to have the equivalent of a physical card. Now, Paul Wenzel is asking, you already consider proof request renderings too? Yes. Actually, I had two colleagues that a couple of hours ago, they, they demo a framework that we have for creating like a resource for SSI for both issuing and verifying. And they are going to be the clients of the HTML version of this. Yeah. Mendi woman is asking, what representation will be defined? Credential definition, issue credential metadata, or predefined in the mobile wallet app? Yeah. Excellent question. So the idea is that you are going to, at the same time that you are like defining the credential definition, right? For the blockchain, you will, you will do the, the SVG and package this with more metadata for the, for the, for the, for the rendering component to render that. The idea right now is to just worry about the use case of like, you are developing your own mobile wallet to, to support the case of like, I have a wallet, I know how to represent this wallet and sending this, for example, the verifier, what comes to mind is using the same channels of areas to send a custom message and kind of like provide some info and some info to the, to the, to the receiving agent. And then that agent can decide how to do it. Now, the key here is kind of like support, right? Like how to, how to come, how to provide this in a way that, that we could expect that a lot of people are going to support this. That, this is what is not clear yet. So if you have ideas about how to, how to handle this, please reach out to me in the GitHub repo. Let me post that again if people are just joining in. Yeah. So also maybe when we release this on Monday, you're going to see this like working on the Aries Max source code. So you will see an example of this on the, on a wallet, on a wallet app. So another question that I have here that I have been asked before is how to deal with different screen sizes. Let's say that you are in a tablet. So right now, I think we have a good solution for the, for something that looks exactly like a card. I will wait for more feedback to the community to, to suggest something to the contrary. But I think that whoever, the idea of this is kind of like a standardize something that, that is like a common problem that we have. If you have something specific, it may be that we just create a kind of like a specific component to support, to support that use case, but it's, but it's not going to be, to be receiving kind of like this, like a standardized attention. So for example, it won't, it won't give you accessibility a feature, but you will have to implement that. Any other, any other questions? Bendy is asking if there is a way to personalize representation from creation claims called having a conditional rendering based on claim value. I haven't, I haven't thought of that. I think the, the conditional stuff seems kind of tricky because we're like building on top of things that are supposed to be immutable, right? Like once, once they are in your card, you know, like in your, in your mobile wallet, you know, they're not supposed to change. I think like in this specific use case, I don't see why not you could, you could I receive this as part of like a hook or something like that. I mean, again, if you, if you reach me out on, on GitHub with this case, I mean, like gives you a, like a better opinion there. Yeah, like, for example, one way to see this actually is to have a, it's, it's kind of like having some sort of like a, the responsive approach and we just, the conditional is like right on top versus in the code. I don't think it's a good idea to come, to add, to turn the SVG template into like a Borneo man program. I think, I think that could add like more, more problems than what it's of. Okay. Any other questions? Okay. Well, if there is a moderator here, please, please advance like the best, the best way to to have the presentation. I want to make sure we have time for the next person. Oh, yeah. So Paul wants to ask, are you working for Trinsic? No, I, I work with the Kiva protocol team. I do, I do know the, the Trinsic team. I, I, I often use them to connect to, I mean, to have like a clear way to issue credentials, like random forms. So yeah, I recommend them for that. Thank you. Thank you, Mac. Yeah, I think Paul, like to give you like a more, like, more on my, on my thought, on your question, I think if, if you saw the presentation from my colleagues, Michelle and Nate Sula yesterday, we have a wizard maker for to create SSI flows using HTML and React components. You could use that with Trinsic and these to provide basically a web flow for verifications and just like render more than the raw data of the presentation. You can provide a representation there. So if, if, if you're like actively using Trinsic, we really want to talk to you. Other questions? Okay. Let's wrap it up with four minutes to the finish line. It was very nice talking to all of you. And I hope to, to connect with you after be, I give hope. Take care.