 So, Oh, I see somebody is here from the cave up protocol. Hi, they've been this. Hi, everyone. This is Shawnee. I'm with Kiva protocol. I was referred to this meeting by Nathan Nathan George who works with Kiva protocol. It's nice to meet everyone virtually. Beautiful. One of the things before we start one is the antitrust policy. We are meant to be part of the Linux foundation, and we follow the antitrust policy of the Linux foundation which applies from wherever you're joining, meaning every jurisdiction as a different slightly different antitrust policy so please read up on that. We treat everybody with respect, even when we are agreeing disagreeing with them. So that's the second. And without further ado, we start the presentations. I think the first one should be Stefan and Roland. As it happens, I think we've, we've, we've slightly rescheduled the. Yeah, fine. If that's okay with you because, yeah, no problem. I've, I think, and I hope that is okay with you hold on but basically I'm going to share presentation with Michael Adams from quality sign in the UK. And I think hold on will, whereas in fact initially was kind of plated that would, we would present something, I would present something generally with all on but in fact it's what I will will make a solo presentation from if, if that's okay with you. Yes, yes, at the end of your presentation. All right, okay. Now, right, I think I guess you deserve. Sure. Um, so, where do I share my screen here. I probably let me see whether I have to. Yeah, it should be possible it's at the bottom of the screen there should be a green arrow pointing up. Got it now. Is that right. Now do you see what I say. Yes, now I see it. Right. Okay, let's put it at full screen. Oops. Do you see it full screen now. We see a couple of things there one is a. All right, okay. You may have to go into presentation mode. I don't know. There are all these little buttons all over the place is any better, right. Yes, this is this is it. Okay. Right. Okay. As I think it's obvious from the title we are games who talk about the European digital identity framework which is called. Yes, this is version two. And the European digital identity Wallace but we're going to focus on on on a topic that has been quite. We think it's significant which is offline use case, and why we believe it matters. I hope to engage in a discount we hope to engage in a discussion on this topic because we know that this is this is a key element. We're going to focus on the payment scene, and it's important that we come to meaningful conclusion at least with the hyper ledger within hyper ledger identity working group as what is possible whether it's possible to use DLT solution in that offline use case or not. I hope we can have a discussion. Anyway, I'm now we're. Okay. So, you probably, you know, we are going to, as you probably know, the last year. The European Commission presented a revision of the framework, which is basically centered around the digital identity what is, and this is basically learning on the limitation and problems of the first version of the data certainly on the digital identity side. It's effectively aiming to implement an attribute base user centric versatile proposal that will have a high price sector focus, and will allow the communication of high aloe attributes. And also recognition that, and this certainly comes after his experience of the first version of the idea that the vast majority of the needs for electronic identity and remote authentication remain with the private sector, in particular in areas like banking. In banking, especially if you're talking about payments. You do need connectivity proximity connectivity and that implies typically offline similar connections. Right. Um, you, for those who are not familiar with that first version published in 2014. Two sides, each of our services that does not concern us here and the main side which is a digital identity scheme. Which is highly focused on public sector use high level aloe is technical specification remaining national and a fairly dated the summer based interoperability architecture. Yeah it has to is centered around digital identity Wallace. It's clearly has the mind of public and private sector use it's based mainly on an accreditation process with common technical specifications so this is no more national and remains fully national fully recognized within EU members face. The, there's also some change on the interest services side but we don't really need to consider this except maybe that from a DLT perspective there is a recognition that distributed ledger registries are to be recognized for us. Services. Now, another important piece of regulation is the forthcoming anti money laundering regulation that is entirely new. We'll define the common identity attributes requirements regulatory technical standards for the simplified and enhance customer decisions, and we'll recognize the digital identity Wallace on the part with ID documents this is already published the draft is already there the ML package is a little bit more advanced and the, the idea is to think the ML package is likely to be finalized before this. Before summer, where is the idea is to proposal will probably take a couple of more months to to come to completion. I'm sorry. This has no doubt you know the combination of the two has a very significant impact on financial sector is pretty obvious but we'll have to see how that translate. Quick word about the digital identity requirements. First, they have to be accredited and they have to comply with common specifications. These are starting to be built. The, there is a so called the architecture and reference framework document that was published a month ago I understand that one is going to make a short presentation on that. They have to be issued are approved by member states so it's, you know, don't don't miss understand the the whole process it remains controlled by the public by the member states has to offer a high level of assurance. It must put the users in full control of the wireless. It has to be accepted by virtually everybody that matters including financial service providers and the so called very large online platforms. They have to accept electronically tested attributes. They have to be free of charge for users, then must create qualified electronic signature sales, then must work offline as well online, and then must support strong customer authentication requirements, typically including when when required for payments. These last three topics are actually quite structural and when it comes to when it comes to, you know, having an impact on financial services. Then there is a number of other, I would say optional features. They have to strengthen privacy there's a little bit of a debate as to whether that's true or not, how far that will go. They have to, you know, they have to allow. Well, they could have lost several identity profiles think about the situation when you have, you know, a private identity profile and work identity profile, for example. And they have to, you know, they could support CVDCs. There's a lot of discussion about CVDCs and now this is beyond the scope of our discussion today but it's important to bear in mind that digital identity wireless will effectively can be seen as a tool to support CVDCs, especially if you see that they are used for payments already. So as mentioned the first draft of the European digital identity architecture and reference framework document was released last month. This is the first draft no doubt. In fact, well, it's the first public draft we know at least one version that was published before. And no doubt more versions will follow. So you should not. You should not assume that it's the final say on this. So far some of this extremely ambitious proposal plus time implementation framework. It has to be said it's supported by there's strong political backing for the adoption of that piece of regulation. The digital identity wallet is really seen as a near universal digital potential. That's how it is presented. Especially banks will have to accept those I mean they there's no doubt that, you know, all key service providers will be required to accept digital identity wallets, including all so called oblige entities and very amount regulations. So it has a structural impact on the financial sector. First, why because financial institution could provide electronically tested attributes that will find their way into the wallet side, you're talking about I bind details card details account information details and so forth. So it's not clear this stage is whether that would imply trust service provider status and very I guess that that's probably will be clarified at a later stage. For customer due diligence processes it's very clear that digital identity wallets will be a clear and clean substitute for ID documents like passport or national identity cards. You know I mean for the it avoids provides a neat way to avoid the so called third party reliance constraints. And it's a key tool for CDD data portability or reusability, but with two caveats one is that the economic model of this has to be established and liability implication have to be clarified I mean this is something that the IF is currently working on for some has been working on for some time, gain has been working is an initiative worth mentioning in this respect as well. And, and last but not least, at least when it comes to the discussion on offline, the wallet will authorize payments online and offline. And this has quite structural implication for the so called landmark payment regulation in the EU which is called the second payment directive. And this is which implies you know which you find so that you need to apply strong customer authentication. I don't know if we necessarily get need to get into the detail of this but that will probably imply that so called redirection mode embedded in strong customer indication will no longer would be needed. Okay. Now, the, if you're looking at the reference architecture and reference framework document there's one very clear requirement that comes out that we have mentioned here it's, you know, which is defined as mutual authentication. Basically, the say that the wallet will have to implement mutual authentication capabilities that implies that the wallet user can can of well the wallet user can of course be authenticated by the relying party but like but reciprocally the wallet user is able to authenticate the relying party. So that process should be possible both online and offline that stated that is the verbatim wording of point four point four. So, you know, it's this is something that that's where we are today. I'm not going to comment too much on the slides because I think this is, in fact, what, what I was going to discuss. Now is. Is Michael still around now, by the way. Oh, I'm here. I'm here. Right. Michael sign. Thanks for joining in. So, I think it's your turn, Michael. And I share my screen is that going to. If you do that, actually, okay. And I'll hand back to you afterwards. No, not to worry. I think you have to stop sharing and then I can have a go. How do you stop sharing? That's right, because it allows only one participant at the time to share. Share screen there's a little arrow next to it. Probably say stop sharing or something. All right. Okay. Sorry. Right. So let me see what I can do here. Right share screen. I thought you had continued with the other discussion. I was 10 minutes late. I did my best. I, I went to the end because I didn't, didn't dare leave. Michael, if you gave a brief introduction to yourself, meaning, you know, I'm going to do that as well, actually. You start first, and then I'll introduce myself. Okay. Well, I'm, I think I'm, I'm a regular participant in the bins group. I've been been around for on and off basis for a couple of few years. I'm a consultant working on regulatory aspects of digital identity and KYC transition for the financial sector. I've been working a lot and I'm currently working specifically with the European commission and other organizations on the implementation of digital identity wireless. And I am partnering here with, with Michael. And Stefan is mostly coming at it from a legal. Yeah, absolutely. I work, I work for years and in, in, in well known bank. And Vicky and I used to be colleagues a while ago, right? Yes. I'm not hiding anything. So my background is what technology and banking side. I worked for a large British bank up to about eight years ago. And I was actually the kind of the product owner for the host to host channel. And I, as well as being the product owner for it prior to that I detected it. So I was in technology and moved into the business. And I launched a startup a few years ago, which was focusing on payment authorization with a mobile phone. So it's a mobile app to authorize payments. And then over the past couple of years, we've transitioned it into the identity wallet space because obviously payments and identity are coming together. And then at least for at least a year. Also, I've been working with Stefan. And we're both members of an ad hoc group called the eWallet Network in Europe. And so I'm going to show you now a demo of how the European Digital Identity Wallet could be implemented, which is based on open international mature standards such as X509 and the Etsy advanced electronic signature standards. So there's no blockchain in here phrase. But we'll maybe become apparent why in a minute or so. So the first demo, I'm going to give you two demos. This one is an offline demo. So essentially, it can work fully offline where the payment, the point of sale terminal or the pay ease app can be offline and the payers app. So on the left hand side, we have the payers or the wallet holders app. And on the right hand side, that's essentially representing the relying party slash merchant slash payee. And the procedure we're demonstrating is essentially a request to pay where the merchant prepares a request to pay. They sign it attaching their attributes and that is transmitted over a proximity connection or an end to end encrypted proximity connection between two devices. The wallet fully authenticates the request before presenting it and essentially authenticates the relying party in the process before presenting it to the wallet holder. Like any identity transaction, they're asked to review and authorize the request and presenting attributes when involving a payment, they're selecting an iBan or a card attribute as well as other attributes. And obviously they're agreeing to pay the amount. And so that becomes a counter signature. So the wallet is counter-signing the request or the wallet holder is counter-signing the request of the merchant slash relying party. And that counter signature is transmitted back to the relying party and the relying party then counter-signs that to provide a receipt. So there is either three or four, a chain of three or four signatures in this procedure. And I'll just click play. Sometimes it doesn't know it does. It is working. That's good. So it's happening quite quickly on the right hand side, the merchant is selecting an account to credit or the payee is selecting account to credit. They specify the attributes that they want from the payer. So they're asking for proof of age. So they might be buying alcohol or something. And that's mandatory. And then email address, cell phone number. Those are optional attributes. They'll complete the sale if the wallet holder doesn't choose to supply them. But it would help them if they agreed. And then they specify the amount. Five euros, 99 click. And now they're displaying a QR code. And there's no sensitive information in that QR code at all. It's really just an identifier to allow the wallet to connect automatically over the Bluetooth low energy BLE connection with the terminal. So there's no I bands or amounts or anything in that QR code is just done and identify that's being advertised. Establish a secure connection. And you can see the wallet is presented the request of the relying party and it's asking for proof of age and they're given no choice on that one. And then they're asked for email address and cell phone number. All the wallet holder can do here is as well as agreeing to the transaction. They can either abort the transaction or they can select an account. Which is also an attribute to pay. So this is these have become the debtor elements of the payment. Select the debtor account. And authorize the transaction and essentially that's it. That's all they can do here. So that. They're now signing it. They're now signing it. Essentially is treated as a qualified signature. Or certainly an advanced electronic signature. It's performing SCA. So now on the merchant terminal, we can see, we can review the payment. And we can do the same thing on the wallet. So this is a requirement of the. EI dust to group in digital identity wallet is that the person can see the history of who they've interacted with what transactions they've performed. So we're now going to just have a quick look at the transaction. And you can see in this scenario, there was a chain of three transactions. So we've got creation approval and receipt all chain together to provide a comprehensive audit trail. And you can see this three attributes have been received. Now, what they're going to do finally is I think it's the wallet holder is going to export the proof. Out of the wallet. And that's just being right. It's going to arrive here on the MacBook. There we go. It's arrived. And now what we're going to do is upload the proof to the European verify signature site. So this is an advanced electronic signature structure. And essentially it meets all the comprehensive requirements of the, the, the etsy signature verification standards. Although you see a couple of crosses here that's because the certificate is in this demo, it's not a qualified certificate. And it's actually not even a recognized root certificate is a generator. It's one I created for demo purposes. So no one's going to trust this root certificate. And that's the end of that demo. And you don't, you don't need to do that for every, for every interaction. It's just, if you need to confirm the check the authenticity of the, of the, of the process, right? Absolutely. So the, the idea is that the, the, the wallet or the relying party can themselves verify the, the complete sign structure. You don't need to do that. And you can do that if you want, but there's absolutely no requirement to do that. And this is, this EU's web, web app is a demo prototype site. It's not there to provide legal certainty. It's there for people to test their digital signatures, which is what exactly what I'm doing here. And they say it's, they say it very clearly do not use this as a, you know, real world transactions. It's just for demonstration purposes. And then the second demo, I'll show you this is a business banking online business, a business banking provider in Bulgaria called Nula BG. And they have integrated the wallet with their accounting package. And the idea is that the user logs in with their European digital identity wallet to the online package. And then they authorize payments prepared by the package and produce a qualified signature as the proof. So the wallet provides the website with the sign proof, which is a qualified signature. And that signed that that proof that is deemed SCA proof that then has to be accepted by the bank as proof that the payer has authorized the payment. And also furthermore, for, you'll see there's tax payments for tax payments, the authorities want a copy of the qualified signature separately. So the business banking package can on behalf of the payer, transmit directly to the tax office a copy of the sign proof, which is a qualified signature. So it's quite a neat use case really and it's demonstrating the business use case, not the personal. So they're logging in. And this time, it's not a proximity connection. It's an internet connection, but it uses the same concept. There's a QR code. And instead of a BLE identifier, there's a URL of Nula BG. So the wallet is going to talk directly with Nula BG. There is no intermediary here. So we've got an end to end encrypted session between the wallet and Nula BG. They select a profile to log in with. That logs them in. And now they're going to go and authorize a tax payment. They have to scan a QR code again, which basically points them at the tax payment. You can see here, this is paying the Bulgarian Revenue Agency 427 euros. And they do authorize that the same way. And it gets refreshed on the accounting package. And then they send it to the government and the bank. So I think that's it. Should I stop sharing? I'll hand it back to you, Stefan, if I can figure out how. There we go. Did that do it? No. Stop share. There we go. So I think at this point, we should open it up for questions, if possible. And then we conclude with Roland's presentation, I suppose. You're. Revealing your. Yourself now. I am sorry. I feel, I feel tower and everything else in the background. Great. So then it seems like you have questions. Yeah, yeah. No, great, great stuff. Both presentations. Good summary, great presentations. Yeah. A couple of questions. So. So I guess I'll do the last things first. You're on the demo. So there was really cool that, you know, you have the transaction audit and you can see what's going on based on the regs, as you said, but I couldn't. Or maybe I just didn't pick it up. You know what. They talk about in the regulation. Where required a unique identifier. But I was trying to see from the information past. What, you know, is there a unique identifier in this? And can you link those transactions or like you say, it's an encrypted channel. And like with. You know, with hyper ledger, because that's what we're talking about here, you know, we could create a pair wise pseudonymous channel using. Unique dibs, you know, we'd never use the same did for any transaction. Do you have a similar. I think, I think I can answer that one. There is indeed in the regulation, a requirement for, I think the terminology is unique and persistent identifier. Where legally required. Yeah, yeah. But what actually happens is this is something that is being has been requested specifically at the request of tax authorities in the EU. Okay. So basically what I think it's, it's not, I mean, it will have to be there. No doubt. Right. What I think it's very likely, although not completely at Chinstone, if you if you said, I mean, is that not everybody will be authorized to ask for it. Exactly. That's why I was asking in this demo. I think only what's very likely that you and me, for example, will have no right to ask for that one. Right. So it's very likely to be that because I think there were confronted to a situation where you have people with you have people with multiple nationalities that were being unreconcilable. With with the current the identity framework, and there was a request to effectively overcome that difficulty. So that came, but it was specifically related to tax use case, not the thing that we have in mind here I think it's, it's very likely that in the end you'll see that yes, it will be this unique identifier, but effectively the case where that unique identifier will have to be communicated are going to be extremely limited. Exactly. Yes. Yes, please go ahead, Michael. Yeah, so the second part of the question was on the end to end encryption and all we implemented was just standard Divi Helman. Lipstick curve Divi Helman techniques, where on what happens is that the, the both parties create key pairs, and they exchange their public keys. And just by some very clever trick. A combination of your private key and your counterparties public key will create the same secret key as they create with your public key and their private key. And that allows you to create an encrypted end to end session, which, you know, this is like a one time ephemeral key pair that you throw away after you use it once. And the so the end to end encryption doesn't authenticate anyone it just prevents anyone from monitoring. And it's the, it's the chains of signatures that are being verified at each stage that establish the trust between the parties. But you totally right. I don't need to say any more than Stefan about this identifier, but what I would say is what we're trying to do is aim so that the principle is that you can walk down the high street and, you know, walk down the line where it's you go to the butcher baker and candlestick maker and you go to each shop and buy something. And no one can track you as you go from shop to shop. So you don't leave a trail that can be joined together and profile you and identify your true identity. And so we're not sharing, you know, an I ban as such or a bank account number that's always this stays the same. You're sharing an attribute certificate with pseudonyms in it that represent your bank account that the bank can issue and you with lots of copies of these things and you can rotate them and hide your real identity. So the the I ban attribute or your card attribute would be linked to an identity attribute, all of which would get really rotated as you move from shop to shop and you can't track the person as they're spending. I think hopefully that's very good. Yeah, that's where I was going. Yep. Thank you. So anything more, Dan. No, please give others opportunity. Yeah, to ask away. Yeah, yeah, let's see whether anybody else has and after all that, I'll ask my questions. Go ahead. So is there anyone else who wants to ask questions? I don't see any hand up, but that could be because people have difficulties putting up their hand. Okay. If not, I'll ask a couple of questions and then we can move on to Mr. Fowler. Right. Hello to all. Yeah, yeah, but, but I'll ask a few couple of questions before you take over. Well, yes, please. Okay. One of the things that you mentioned when you were talking about. The offline use cases that use of a smart device of some sort. Right. I mean, it's got to have some way of establishing a NFC with a, with a payment portal. Is that, is that correct? Does it have to be a smart car? Smart phone or can it be a smart phone? Yes. Is there anything else like a card or something smart? You're really talking about, you know, an application on a smart phone, nothing else. I mean, that's really what it's likely to be. I don't think there's any other practical. Actually, there are. The Chinese. Interestingly enough, I've developed. I know the human for the EU one, right? No, I don't have an offline use case as well. Yeah, I know that I know that they've been, but I think realistically, I mean, you know, 10 years from now, who knows. But today, I think, you know, it's hard enough to agree to, to this, I think really what they have in mind is. I don't know what Michael thinks on this, but it's really an application on a smart phone that is interacting with relying bodies. And in fact, that's a good providers. Nothing else for the time being. I think that's, that's ambitious enough to do that. Well, there is a use case based on eco. This is for travelers and for onboarding certificates. Based on a cure codes with. But this is really, I don't think really practical for the payment. This is much too short. And there is a one link between the onboarding and the cure code, which is impossible to bear with the payment use case. Can you repeat that? Sorry. You cut out. You're saying that you didn't think the QR code was appropriate. No, he said that there's another use case, which does not use the. That's not use a smartphone, but he doesn't think that that could apply to a payment use case with that. Yes. I can't hear you always international civil aviation organization. And this use case is based on a printing a cure code on the boarding card, which is I believe a completely impossible to use for your use case because you need to interact very efficiently between the payer and the provider of the service. So I believe the only way to work is on a smartphone. Yeah, I mean, there is. There are some smart cards that are capable of this kind of protocol where there's interactive protocol, which is what basically you're talking about. That's what the Chinese are, are implementing. But I don't know, you know, that's, that's a different story. Depends on whether it's a rural area, people don't have smartphones, you know, all that stuff, or even just a payment card, which they get in the mail or something and that, that can be used. But anyway, let's not go deep into that topic. The second thing is you said that there is a verification of, of the relying party. Is it anything more than something like a, like a TLS type interaction, because everything, you know, all the, all the encryption and everything is today done by using either TLS or HTTPS or whatever, whatever, whatever the stuff is. If I answer that, this is a really important point. The requirement is for the wallet to authenticate the relying party while it, even while it's offline. That means that it cannot call out to a remote server to help in that, that verification. Now, this is why we, when we implemented this, we didn't use the, you know, the W3C standard. Instead we use the much more mature, you know, X509 and advanced electronic signature standards, which allow you to verify a counterparty signature offline and up to the full certificate, verifying the full certificate chain as well as the signature and mapping, matching the, a trusted certificate, for example, the root certificate of the counterparty with a local copy that you have on your smartphone. And that by matching those two with a local one that you sourced from a trusted source, a trusted list or something, you can then, you can then trust your counterparty, because you've authenticated your counterparty because you've verified the full chain, the signature and mapped it to the root certificate. Essentially, you can verify offline in that manner in the same way that you would verify online with one exception, which is when you're online, you can make a call for a real-time certificate revocation check. Clearly, they can't do that when you're offline and you just have to accept it. But that's the only compromise that you need to make. So there you go. It has to be verified entirely offline and not requiring an internet connection. Yeah, I mean, even today it happens that way, but without, because there are browsers in bed, some of the root certificates and of course it uses internet, but theoretically, if you have a protocol to exchange information with another device, which like Bluetooth or whatever, NFC or whatever kind of interactive protocol, then you can do the same thing yourself. And I agree that you have solved the problem by implementing this in Bluetooth or whatever else. But the basic idea is there in browser's list of, you know, trusted list. And in fact, yeah, that's one thing. Dan, you had something? Because in about one or two minutes, we should pass it over to... Yeah, I just wanted to say that's basically the way that MDLs work. And the other thing, and Stefan mentioned this, where it implies a smartphone is not only do you need to authenticate your mutual authentication between your wallet and the relying party, but you and your wallet, they require strong authentication and they do talk about multi-factor authentication to the wallet and how you're going to do that without... And there are biometric smart cards, you know, that are contactless anyhow. But it's going to be tough to do authentication to your wallet without a smartphone, especially because they call out multi-factor authentication. Okay, that's true. Yeah, I mean, biometrics on a smart card would be a tough thing to do, I think. But it's possible. I mean, it's coming. It's definitely coming. No, no, it's here. Here's one right here. There's a fingerprint sensor on that card and it worked. To me, the most important point with payments is there's a requirement for dynamic linking, which includes the display of the payee and the amount. So if you are the payer, i.e. the wallet holder, within your trusted application, you should be presented with the payee and the amount before you are asked to authorize that payment, which is only logical sense, but that's in the regulations as well. And if so, if you don't have a display, how are you going to review the payee and the amount? Actually, the Chinese have demonstrated a single line display on a smart card. That can actually display those things. But anyway, like I said, we are going into this, you know, a rabbit hole, which can take us to the other side of the world, which is China. Anyway, it's not a rabbit hole anymore. It is a hole right through the center of the world. There were several objections, so to say, in the Evernon paper about, mostly about the government, you know, being authorizing not just the, not just the issue, not just the wallets, but also the relying parties. Yeah. You read that. Well, I mean, yes, I think there's, I mean, two things. One is the fact that national, well, European governments are going to be in control of the issuance of the digital identity wallets. That's, I'm afraid that's the fact of life. That's the way, that's the way it's going to work. Yes. You know, it doesn't mean that we will be issuing the wallets. For example, in Belgium, the government does not issue the wallets. The wallets, they, well, they does not issue currently the digital, the main digital identity solution. It's provided by Belgium banks, but it's recognized by the Belgium government. So that framework of either issuing or recognizing officially the wallet will remain. There's no dispute about that. There is indeed some requirement that relying parties should be recognized. Somehow I can't exactly remember the wording that has been used. That is something that I personally find quite strange. It's, you know, we did discuss with the European commission, we said, you know, what do you mean by this? You know, how is that recognition process going to take place? Apparently they have in mind as kind of low key compliance with, well, sort of compliance with a set of basic requirements, a list of requirements, how that will work. It still remains to be seen, but I do agree that that is a point of attention. They are probably look forward building a certification framework based on minimum requirements for these parties. And this part should be precise, of course, in the draft framework, which is really very thin and not precise enough to give, to provide good information to all the actors. So Rolanda, I think we have come to the time when you should be taking over and running this to the end, because we don't have much time. So you want to do your thing? Well, we can go over by a few minutes, but, you know. Okay. I wanted to point out, can you see my screen or not? Yes. I precisely wanted to point out some key points of the document which was linked by Dan. Thank you, Dan. And can you really see my screen? It's good? Yes, yes. Okay. Firstly, I want to, because the time is short, I want to put the stress on the real status of this draft. The regulation is still, I think moving with the expert group. So I think that it's quite interesting to provide requests and also some objections as the event in the document, I had, I didn't read it before the call, but I just have two or three minutes to read it down. So that's quite interesting. And some, I share many of these, many of the points which were expressed in this document. I want to point out on this slide and nature of, you know, an ecosystem. And you can look out on the blue parts. These are new existing entities according to the EDS2 regulation. And you can also look after the providers of registries of trust agencies here and PKD and trustee, trustee is that we were speaking about. And that should be much more precise, but by EU authorities. And of course, the relaying party, which is, of course, a point that should be controlled and certified by an accredited body, which should be at the end one of the main control means in order to keep a good level of assurance for the end users. Well, you mentioned one point that was important for me too. That was the difference which was made between the personal ID, the PID and the other attestation of attributes. And there's one main question which is, Nick, is the question of the unique identifier. And to my mind, it's very important that the unique identifier should be the key and the functionality, which is very necessary to offer interoperability. You remember that even if the wallets are issued by member states or by organizations that rely on the member states, there is a request for interoperability across all European countries for cross border operations. So that's the reason why the unique identifier is very, very important. I believe it's not enough on the spot, on the draft currently. Have I got some more? Yeah, you can use a little more. Yes, okay. And there's also here in the request and person identification data with electronic attestation of attributes here, a difference between qualified and non-califined providers of electronic attestation attributes. So that's a real question because what we were thinking about in our reflection on the drafts, is that there is a risk that for the end user, there is not the same level of assurance between the two. So we consider it as something that could appear as a risk of lack of trust. And that's the reason why we were thinking about different use cases for the beginning of the implementation, only qualified electronic attestations of attributes and not working for non-qualified ones. Yeah, but you know, the main use cases will imply non-qualified electronic attestations of attributes. I think that's the difficulty because effectively, I mean just take the example of banks, bank information. It's very likely that banks will certainly become qualified trust service providers. Still, you want to use banking data. Okay. And banks are not going to be anytime soon qualified trust service providers. Okay, that's a good example. So in your opinion, they will not move forward this position? Well, I mean, I don't know, but I can understand the decision to extend the user to, well, to extend the range of attributes from qualified to qualified and non-qualified. I mean, that does make sense to me. Okay. Yes, I agree. I mean, if you're talking about, you know, the core identity data, your first name to last name, date of birth and so on. So you probably shouldn't, you know, you shouldn't be, you should not rely on something that is unqualified because that's, that really makes, that can make a big difference. But for certain set of data, it doesn't really matter. I mean, and frankly, if you're saying, okay, only qualified EAAs will do, you are going to drastically, drastically limit the relevance of the, of the proposal. Okay. Our question was from a legal basis, which will be the, the situation of this non-qualified EAA. Will this present a risk in order to... Well, they're non-qualified. I mean, they, you know, they are available, but they're non-qualified. I mean, they don't have the same level of quality. So to speak, but, you know, they can, it doesn't mean they can't be relied upon. Okay. So it looks like this exists even today, right? I mean, we have data from all kinds of sources available about somebody. And then you can say, okay, like you said, you know, we only admit in the United States, the DMV license as a identifying document or a passport. We're not going to just say, take a card from a university saying, you know, the person is, but you can add that to the list and say, okay, this is really me. This is really me, you know, five non-qualifying things can add to the, to the surety of the information. You know, if you're, you know, if you have a library membership, for example, or, you know, nonprofit organization membership, whether that, you know, that attestation could be, could find itself in the wallet, does it need to be qualified? No. I mean, it doesn't need to be qualified. You see? I mean, there are, there are loads of use cases where this is not a useful requirement. Okay. Well, probably we are, as we focus on a sensitive application and use case, and probably we, we look, we feel it as a risk, but I understand your position in a general use of the, of the word, which is of course the, the goal of the regulation. Okay. And the, the pay, the personalized identity information, they, you know, they don't specify qualified or unqualified, but if it's going to have any value, if it's going to be trust, then it should come from a provider. If I say I'm Dan Bach, and I'm because my library says I'm Dan versus my government. Well, you as the relying party have to take that in consideration. My concern was and still is a persistent, unique identifier that should not happen with every transaction. Another that's very clear. I mean, that's, you know, that's crystal clear. You have, you have to, you have to understand why that persistent and unique identifier request has been, has been initiated. Clearly, first of all, it will clearly be treated as the same sort of attribute as poor identity attributes that will be provided. It will benefit from a high LOA status. But it's, I think equally, well, maybe a little bit less clear to everybody, but equally clear to me that it will not be allowed to be requested by just everybody, because otherwise that defeats the whole purpose. I mean, that's, you know, that's a huge breach of privacy. It allows monitor, you know, tracking. It allows the tracking of usage. It's pretty obvious. I mean, people know that they haven't quite defined the, how it's going to be worked out, but there is already a lot of discussion about, you know, the need to respect privacy when dealing with that unique identifier. Okay. Probably we will, we will go on next, next time. Yeah, yeah, yeah, I mean, you know, we should, we should stop soon. In fact, it could be good if we stop right now. And we can bootstrap another discussion about EIDIS because it is an interesting topic because it will become the standard that we all look up to just like GDPR. We are going to be following the Europeans here in the United States, I'm sure. No, maybe, maybe. I mean, the, you know, the Apple mobile identity driving license wallet is an interesting example as well. Yes. And it's supported by an ISO standard, the 18013, which is, which is relevant. I mean, it's, you know, I'm not saying one is intrinsically better than the others, but certainly the two are worth considering. I will introduce the concept of EIDIS breach API, which is a probable link. And which is still under test between SSI and the EIDIS framework. But there are some questions of, you know, smooth implementation between the two. And that's the reason why I, it's an interesting point of discussion that we probably can open next time. Yeah, yeah. And I would chime in on the next time maybe, I put in the chat, the Canadian digital identity wallet draft that's just been made available for public review. You know, to the whoever said it before that, you know, this EU digital identity wallet may have legs. And yeah, it'll be interesting to talk about that against the MDL, which yes, is an ISO standard is Stefan pointed out, but it's, it's, it's got a lot of holes in the standard. And, and yeah, it's, that might be a separate meeting. Yes. So Roland, if you don't mind, we are going to, we can end this year and we can reopen the, with somebody from the Canadian side, presenting on this, and then we can contrast it with the, with the EIDIS and, you know, we can explore this further at that time. And also what will be useful is, especially the whole use case in the capital market, CBDCs and so on. That can happen inside the capital market sick, which I also chair. So, you know, we could, we could do that there. So thanks, you know, everyone and you should share this Roland, the, your presentation and also the other, other two gentlemen, you know, Stefan and, and Michael. We can share the presentation with the link to the demos, right? So people can run the demo separately as well if they think it's. Yeah, yeah. We can, we can do that, those three things and put it in the meeting page and I will send it out on the identity mailing list. Okay. Now I think we have really exceeded our time. Thank you. Yeah. Thank you so much. Thank you.