 I would like to give you an overview on two other initiatives that we are conducting at OpenWallet Foundation. The first one is the Credential Profile Comparison Special Interest Group. So we have two mechanisms at OWF to have long-standing or short-term activities to investigate in certain topics and the Credential Profile Comparison Special Interest Group as the name suggests tries to compare different Credential Profiles, which what does that mean? Out there in the wild are a lot of different ways you can represent Credentials. We have heard about those in the presentation. The wallet worker uses Anon Crads. The Ping uses Jots and SDJots, Mossip favors JSON-LD. We have heard about MDoc in the presentation of David and so on, but there is much more than that. This activity goes back to I can't remember exactly which IOW, but it's about two years ago and I called a session for those of you that are not familiar with IOWs and unconference so anyone can call a session. And I ask one single question, what's the best Credential format? We ended up in a room packed with, I don't know, 20, 30 people and anyone wanted to sell his or her Credential format to me. It was amazing, really amazing. And that turned into a huge Google Sheet with the different formats and all that stuff and then we proposed or brought that activity to the OWF because we believe that OWF is the best home for it as it is technology-agnostic. Let me put it that way, right? Anyone can bring any project implementing any kind of technology to OWF and we believe that the Grantial Profile Comparison Special Interest Group will help implementers to figure out what's the best solution, what's the best fit for their problem. The problem is that for different use cases and different requirements there might be a different solution and the different capabilities of the different Credential profiles previously were intransparent so it was impossible to really compare them. And that's why we are trying to do in the Special Interest Group, it's led by Mirko Mollek and I've got a pleasure to support him as a co-chair in that group. And what we realized is that in the end that space is a multi-dimensional space. So we've got representations like Seabor, Jason, whatsoever. We've got different signature algorithms. Sometimes there is a relationship. For example, for enocrats there's only CL signatures. For JOTS you can use nearly any kind of signature that is available, even HMAX. And Credentials have a life cycle, typically. So you need a way to manage that life cycle which is called the revocation. And a Credential has key material, key material for the issuer because you want to know whether the Credential is authentic and in most situations if it is about a natural person you also want to make sure that only the legitimate holder can present the Credential which is typically done using key binding. And David spoke about that, that for example those keys should go in a hardware module so you can't expert trade them. And on top of that there is trust management. Meaning if you're able to authenticate a certain Credential how do you determine as a verifier for example whether you can trust that issuer for that kind of Credential. So a lot of different things and you see in the right hand side how many options we have collected so far and if you combine all of them it's three million combinations. So yeah, it's an emerging space. What we did is we put all this in a matrix that people can use as a tool. And I'm going to show you the matrix in a second. So you can take a look on what existing profiles are there. For example ISO 18 or 13-5 for example or the endocrates profile is being used by Hyperledger and you can see what the capabilities and the properties of those are and can combine them. And what we for example figured out in one of the research projects we do in Germany it's called ID Union. We were looking for a successor of the endocrates that we had used before. We were looking specifically for a Credential format that is privacy preserving but also has hardware backed security. And using this matrix we were able to figure out that there are two capabilities that today exclude each other which is unlinkability, CKB and hardware backed security. And that made the selection process much easier, right? So that's why for example we don't use GSNLD and BBS and also not Adencret because they are not hardware backed. But we went with SDJOT for example in that case. But MDOC would also be happy in a solution. Yeah I think I just show it to you, just give me a second. So that's actually the matrix, I think I already filtered. So you can see there are, we have a couple of different pre-existing configurations how people use stuff, so for example ISO MDL uses MDOC, ECDSA as a signing algorithm. It does not use a revocation mechanism per day per se but medium term exploration. The public key of the issuer is maintained in an X549 certificate and the holder key is managed as a Corsay key. And there is a special kind of list that lists all the authorities that can issue MDOCs. If you scroll to the right hand side you can see for example information about who has implemented this particular profile, what technology is based on and the security can be found. Here's all the unlinkability support. I'm looking for the hardware backing. Ah yeah, the hardware support. So you see ISO for example is able to support hardware security, right? And if you don't find your particular profile, you can use the configurator and pick and choose your credential format and your revocation mechanism and so on. It's all nicely being shown then. And what's underlaying that is the different dimensions. As I said, we have a couple of different credential formats as far as I remember, 17 of them where you can see all the different details where's the specification being hosted, what's the kind of process, what's the IPR related to it and so on and so on and so on. You also can see there are a lot of question marks and that's the ask we have for the community. We need contributors that help us to really keep the information up to date because that stuff is evolving at light speed, right? So what you have collected now is really outdated in two weeks from now because the competition is hard between those different standards which fosters innovation. I absolutely like that and the transparency that we have with the metrics even more fosters this kind of innovation. Okay, we are working on extending the data set, making sure we are up to date with the data that we have in the metrics and in the end what we want to do is we want to provide a tool to the community, to implementers of all kind so they can meet a decision really on a rational basis and not just on feeling, right? And that worked well so far for those that used it. Any questions on that? Okay.