eIDAS 2.0 & EU Digital Identity Wallet - Potential, Challenges, Use Cases

Firstly, can I just say you should all give yourselves a round of applause for still being here on Friday morning? Thank you. I thought there'd be like two people here.

So anyway, you're here to hear all about the new secret project. I dash 3.0, who's come across IDUs 3.0. No.

Okay, we're only kidding. That's next month's job. So the agenda today, we've got a packed agenda, some amazing, fantastic speakers, and it's, it is seriously good to see you all here because this is the biggest digital wallet, digital credential program in the world. And it's gonna be either massively, hugely influential and change the lives of European citizens and, and citizens outside Europe. It'll either do that and be incredible or it'll be just rubbish. And it's up to us in this room actually, to make it work.

Okay, so what have we gone today? So I'm talking about challenges, opportunities, and use cases. I'm gonna give you six things to think about. I came up with six is actually quite a lot more than six, but six is good enough to start with. Ben. We're talking about standards and tech, technical architecture. There's been a lot of discussion about protocols, the sort of fact that there's profiles of profile one and profile two and different protocols underneath it. How is all that that is gonna work? So that's gonna be explained to you fully and you'll completely understand it afterwards.

Ben readiness. So this is gonna be really interesting from, from Adrian. There's legislation coming down the line that means organizations will have to interoperate with the, the IDAs wallet. So we'll figure out what that means. How does an organization get ready for it? Because organizations need to start planning now. Then we've got, Vicky actually is going to talk us through Vicky's, like the IDAs whisperer, right?

Vicky, she, she's plugged into everyone and everything that's going on in Brussels with policy makers in different countries and so on. So she's gonna give you the inside track on what on Earth is happening on the, the legislation, the policy side of things. And then we're moving on to, Dirk and Conrad are gonna talk about what's happening in Germany, okay?

And, and how e i d works in there. So Y's here as well. Can I just say y good work, good work on the conference.

Yeah, I think, yeah. Isn't it better than being in that place in Munich where you were trapped in the hotel and the only place you could go was a, a trucker's kebab bar down the road? This is much better.

Okay, so you need to get a move on, really, I should say I work at Jen, so nobody really knows who Jen is yet, but it's, it's a new brand. It's the world's biggest cybersecurity company formed by the merger of Avast and Norton. So all the brand, all these brands here are all under Jen, including this one, which was Nym that I used to work with.

So, Nym got acquired by Avast, and Avast got acquired by Norton and now has become Jen. So I'm on email address number four this year and navigating through another, you know, expense system and moving from Google to Microsoft.

So that's, that's what we do. You'll know a bunch of the, the folks from the X seven M side, like drum interviews here somewhere.

There is, yep. So we do a bunch of things here, but also we've got 500 million end users. So in the world of SSI and credentials that we've come up with, as, as Nym, we kind of could only have dreamed of, you know, having 500 million end users to give wallets to. So now we're in that company and the, the problem changes, we're now gonna work out how to do that. So it goes from vision and dreaming to, to how to actually execute, which is always a bit trickier.

So let's, let's come onto IDAs now. And if we look at the kind of the promise, if you look at the IDAs legislation, the, the introductory piece there, it talks about a whole load of benefits. It talks about some of the mistakes with IDAs one and making it too prescriptive, not making it open. Too few use cases, not bringing the private sector in, not involving citizens enough, which is essentially why IDAs one wasn't a huge success. So now we're talking about something very, very different. It's going from a very sort of simple, hey, you can do a federated log into some government service.

It's going into an open digital wallet that can have any credentials for any purpose, right? And that will be backed by some legislation that defines how some things should work. But it leaves lots of flexibility for people in this room to figure out how everything else works and how to make it really attractive for people. So there's a huge promise here, which is for businesses and governments, you can digitize processes that previously you couldn't digitize, were previously too expensive to digitize or too complex or had too many privacy regulatory issues.

So you can get massive cost savings and you can actually launch new products that you wouldn't have been able to launch before. Okay? So feel free to come around the front, by the way, if you want to. No problem. So huge opportunities for industry governments and then for peop for people, they now will have something that they can hopefully trust. Just come around the front if you need, no problem. They'll finally have something they can, they can trust's, got government backing behind it. It's got some legislation, it's got how to handle things when they go wrong.

So for people, there's some really amazing capabilities that they don't yet know they need. And we in this room will have to figure out how to tell them. So that's the vision for, for IDAs. Two digital wallets for every citizen with a bunch of legislation backing up how it should work. And the key thing is open for innovation, right? There's loads of room for innovation. We also have a carrot and a stick here, okay? We have the carrots of all the things I said, like low friction onboarding, high security, high privacy government, back credentials, finally that are useful.

And then the stick is a whole bunch of legislation that's gonna say to organizations, you've gotta do this and here's how you do it. So you must comply. And that I think is really significant. This combined carrot and stick is gonna make a, for faster adoption and for all those in the world of supplying digital credential exchange platforms to businesses. I know there's a few in the room. The golden years are coming finally. So here's the six things to watch out for, and this is stuff I've picked out of the architecture reference framework and legislation and various other bits and pieces.

So there's just six, but there's a, there's a lot. Okay? And I'll go through these one by one. These slides are gonna be a bit wordy in that you'll see a lot of words. So if you wanna take pictures and take pictures, it's all cool. I'm not gonna talk about all of the words in detail. So some of the areas I've picked out of that we need to watch particularly carefully. Number one, there's this concept of trusted lists.

Now, trusted list is this issuer is authorized to issue this transaction. This wallet is an approved wallet. There's gotta, these things have to go in list somewhere that are stored somewhere, okay? And there's a lot of member state specific implementation issues here. Like it's up to the member states how they'll do a lot of this stuff.

So we could end up with 27 member states each with their own trusted lists for who's allowed to issue credentials, who's allowed to verify what, where a revoked indicator goes for a credential list of wallet providers, you know, lists and lists and lists and listen and lists. And at the moment we dunno who, who's really gonna run and police these. We've got some inkling of, of some of that. But also who pays for them? Alright? How are these wallets, these apps gonna manage them?

You know, with Evan, we spent a long time building one of the first SSI did base credential wallets and it's really hard to have it use one trusted list, which in this case was a a ledger, but it could have been a a, an Excel spreadsheet on Charleston's laptop. If you have, everyone trusts that, which I'm sure everyone would trust that. So how the wallet's gonna make this work? Okay? And who's gonna be the first to build the trusted list of trusted lists? There is gonna be a problem here, there will be so many trusted lists, you'll need a list of which trusted lists there are.

And whoever runs that is in a position of huge power, right? Because if I'm a hacker, I go after the trusted list. I don't go after your wallet, I go after the trusted list. Cuz if I can get, change a trusted list and make Vicky the issuer of digital passports, that's a lot more effective than trying to change everyone's individual wallet. Okay?

No pid, no problem. Who knows what a PID is?

Hands up, who knows what a pit is? Oh, that's epic.

Okay, everyone's been doing their homework. Personal identity data, it's the, the regulator really defined set of data that a government will issue to the citizen in a form of a credential. And I'm using the term credential a bit loosely and it's, you know, well these guys will tell you later the format and the protocol for the issuance of those. So there was a point as the legislation was being debated, where the wallet would only work with a PID in it, okay? So government would have to issue a PI into the wallet to make it work. And there was a lot of pushback against that because why?

Why create this beautiful, open, multifunctional digital wallet if everyone has to go through the hurdle of getting a bid first? Why can't I use it to get my boarding pass or my bank card or my gym membership or my EIC sticker? So thankfully that's been changed. So the wallet will work without a pi and that's fantastic because it removes a whole load of barriers to entry and to use cases. So what it means is as soon as these wallets are available, any organization can start issuing any credential into them within reason. Okay?

But that opens up a huge amount of innovation that's absolutely fantastic. You should note that when a pit does go into a wallet, the wallet state changes, okay? And once it's the pit is in there that the wallet is in, then a different state that is like a more high assurance state, but it doesn't mean you can't do anything else. So that's really, really good news.

Next up, something to really pay a lot of attention to. I spent seven years at Nym on how do you figure this out? How do you make sure that an issuer can't track everything you do with your credentials, right? If there's a possibility for an issuer to track everything you do with your credentials, first of all it's a privacy nightmare for you and it's a regular later nightmare for everybody else. So you need to have the ability to decouple issuers and verifiers. Okay?

The best way to think of it is, is like this, if the second point, if issuers can track you and the use of your credentials, they will, right? We might all think, oh it's all gonna be great and there'll be some legislation, but someone will find some loopholes in the legislation, they'll figure out a way, et cetera. So this is a vitally important point for the privacy and the consumer confidence in these wallets.

Because if anyone finds out or thinks that they, whenever they use their bid or they use their, I know their digital passport or whatever credential they get that an issuer knows everywhere they're going, they're not gonna use it. And the newspapers, the tabloids will have a field day. The privacy people will come to, you know what they're like, if they just get an inkling of something that might be a privacy problem, it'll be in the newspapers everywhere. So we have to be really, really careful about this.

Now, as, as you see on the left, the quotes out of the A R F, okay, it says on the left there these, so this is like acronym land and I'm sure a lot of people know what A Q E A A is, but it's a qualified electronic attestation of attributes, which is like a posh credential, okay? Means it's come from someone who's been certified to issue it. So it says there in the RF that they shouldn't, the issuers shouldn't be able to receive any information about the use of credentials.

Okay, that's great, fantastic. But for the period it doesn't say that. And that for me is a big problem.

Also, if we look at, in fact, maybe there'll be a question coming up in the standards, the, the protocols and the tech bit next about this, the difference between the come on in about the differences between the, you know, the MDL protocol and the O I D C for VC protocol and, and what sort of protections they have to decouple issuers and verifiers. Because if we get this wrong, it's the newspapers, the media will kill it before it even has a chance to succeed. Okay? So we need to be really, really careful about this, this piece.

So anyone who's building solutions, anyone like me that's in any of the large scale pilots? And I know there's some of you here, anyone, I dunno if there's anyone from the guys building the reference wallet here, but just we need to figure this one out. Okay? Cause it's not, it's not good enough yet. The question.

Yeah, we'll take questions. Yeah. Yeah.

Do you, Mike maybe Can answer that working Closely to the center. You quote something of the a rf but a RF is not a legal document from me, correct? It's a working document. Yeah. So I dunno if anybody in the room, maybe you Paolo knows exactly what's stated in the AI dust regulation, which is now in the tri log because that's the only text that will remain.

Yeah, Yeah, well you're exactly right. And may maybe, could you store that one up for when you, you do your presentation, is that okay? Because the a R F is the technical interpretation of the regulation and it has to be right, it has to be correct that the problem is the A R F and the regulation are moving in parallel. And if I was, it's a really hard job, isn't it? You've got to create the technical specification without knowing the requirements, which is always a, a nightmare.

So, so yes, I've, I've put the a f up here specifically. Okay. Can I ask you another question? Cause Of course everyone I think here agrees we should couple Issues and, and verifies. Do you see a problem if the wallet knows where the credentials are being used? Especially if we were to enter a very, you know, concentrated wallet environment?

Yes, that's a, yeah, I, yeah, really good question. Daniel. Daniel from the Open Wallet Foundation doing good work there. So the wallet is gonna know where you use your credentials because you are using it to use your credentials. The question is, where does that data go, right? And what can the wallet provider see?

And again, what might the legislation say about that and how does that get converted into the I f So I think this is, so I would say of course the wallet will know cuz you're using the thing. Okay, but the provider, exactly. And what can the provider do with that information? And when you get to the world of hybrid or cloud wallets where you might have the keys on the phone, but the the wallet is in the cloud and therefore someone's got the data, you know, the keys might be decentralized, but the, the data is in someone's database, what will they be able to see?

So I dunno the answer to how that's gonna be implemented yet. Probably nobody does. But I think you've raised a really important issue, which is the, the technical speck, the A R F is being written at the same time as a requirements are being written. And that interaction and how the requirements are manifested to match the legislation is difficult I think.

And I, is there anyone here in the toolbox team, anyone in the toolbox team who are writing the a r f? Okay, well Paolo, okay, so Pao will answer that question later. I think that's fair, right? It's a Friday Palo, you'll be on in 20 minutes, mate.

So, okay, let's move on. Got, what are we on there? Number four or five, I think. So the missing networks, so we talked a little bit about these trust lists and many, many trust lists and trust lists of trust lists. And what are they, where are they gonna be held?

What, what format are they in, who runs them, et cetera. And well these, if we look at the trust over IP framework, which a number of these people in this room have devised, it's a way of mapping the component parts of a digital credential ecosystem. Think of it like that. Okay? So I'm not gonna explain it all in detail other than that it's really good to be able to figure out if you've got any missing bits in your ecosystem. Okay? And layer one is where your trusted lists go. And there's nothing yet about what, what layer one is yet. Okay?

It could be sey, there's European blockchain services infrastructure, it could be an Inicio ledger, it could be fin, it could be toons, laptop. Okay? So this is still to come and this is the, the reason this is really important is this is where the hackers are gonna go. This is the root of trust for the whole thing. So you've gotta get that right. Huh? Question. Keep Mike busy. Thank you.

Or maybe a suggestion, I don't know, maybe it would be a good idea to like build the standard standardized structure of trust is lists of levels of trust is list like dns, you know, so it could be one way, not two or three ways. Like maybe you have three levels of trusted lifts and you know who, who makes which level.

Yeah, who's responsible or which level, something like that. Yeah, absolutely. So if you look at this trust over IP framework, the reason I like it so much is because it combines the tech, right?

What, what, what technology building blocks do you need? And the governing authority, the definitions and so on.

Gentlemen, I'm not gonna let you speak mate, because I've got 10 minutes, not not three hours. I'm being nice drier, don't applaud that. This is the Drummond 43 Seconds. So one thing that there have been a few criticisms about this, this trust over IP model is a bit did specific ledgers and nodes and that, don't worry about that, that's an example of technology that sits under the skin. It just happens to be written by people who are in, in the, the dead world and so on.

The, these can be any, any tech platforms. So in our EWC consortium, one of the large scale pilots, we are gonna map, we are mapping, we are on the, in the process of mapping I D A S onto these components to see which gaps we've got.

Anyway, what was my point here? My lost my point. My point was we need to know what these are, what the tech platforms are, what the governance is and who's gonna pay for them, right? There is no talk in IDAs land at the moment about who is paying for stuff. So just say again, it's for free. It's for always free.

Yeah, of course. Yeah, yeah. That we're all here charities. It's nice to see so many charities in, in the room.

So that, so that's a big gap. So that, that's still to come. And what we need to do is be cognizant of the fact that the A R F is version one and there's a bunch of people working really hard. They know these, you know, they've got a, they've got a backlog of stuff they're working on, so it will come okay, but it's just, you need to be aware of it. Next one is about unique identifiers and I think there's a lot of confusion around unique identifiers because they can be quite confusing.

So I've, I've made a table to define them into three into three types with levels of badness. So one of the reason people get confused is to say, well of course a credential has to have a unique identifier. If it's like a passport credential, of course it's gonna have your passport number in and of course it is gonna have that. Okay? Of course it is. The PID is gonna have a unique citizen ID number in it. So a unique identifier and a credential is not necessarily a bad thing because we all have them.

Now here's my passport, it's got a passport number, it's unique, I carry it with me and I can present it. Same thing here. Okay? So these are not bad. If you know that the trust that you, you can trust the verify who you are sharing it with, that they're not going to do the wrong thing with it. Like store in a big database and compare it with all of the other things you're using that credential for. So unique credentials and identifiers.

Let, we need to be quite chilled and relaxed about that. Some legislation will define whether relying parties are allowed to ask for this stuff. So it gets a bit techy here. Credential specific unique identifiers in metadata, right? Is everyone still awake? What does this mean? So an example would be I'm issued with a driving license credential and it has, the way I, the way it's revoked is it has a unique revocation number that's hidden in the metadata. I don't see it in the credential.

And every time I share that driving license credential, the the revocation index number where you go to a trusted list to find if it's revoked. Every time I share that credential, I'm sharing that revocation index number. That means everyone is getting a unique number for that driving license. Thank you Mike. Another example is an issue, a signature. So this is where you need to delve a little bit into how the protocols are working.

If the issuer signs your credential and every time you share that credential or they sign an attribute and every time you share the attribute, you share the issuers signature. That issuers signature is a unique correlator to that credential and therefore to you. Okay? So we need to avoid these. I've said here they're very bad everywhere that credential is used. Cause if it means, and I'm not picking just driving license cost MDL and all that stuff, I'm just giving it as an example.

But if everywhere I use my driving license, I'm sharing without any way to not share it because it's part of the underlying protocol and it's part of the metadata that's shared. If I'm sharing this unique identifier, what it means is that everyone who I share it with can get together and pull together bits about me and build up a big picture, which is what Google and Facebook do. So that's why they're bad. And we should avoid that everywhere that credential is used. Let's get really, really bad hold a specific unique data in the meta in in the, in the metadata.

So this would be, for example a wallet serial number. So whatever credential I share, every time I share it from this wallet, a wallet serial number is shared. Which means every time I use a wallet, somebody knows it's number 1, 2, 3, 4. And they can piece together all of these bits about me and pull together a picture. And why is this particularly important?

Well, the IDAs legislation allows for proxy services. And a proxy service is a service that can perform verification on behalf of the relying party. So all of these retailers and shops you see out here, they're not gonna want to spend ages building systems that, you know, credential platforms and all that sort of stuff. They're gonna buy an API from a proxy service. So that proxy service, if they see a unique number that identifies Andy and they pull all these pieces together, then you know, that's, they correlate everything you do and it becomes what we call a global super cookie.

So these are really incredibly bad. So anywhere this is, this is why there's been a lot of, you know, don't put wallet ID wallet IDs in. It means the tech needs to work to stop this happening.

Oh, two minutes, geez. Okay, this is the last one. And then I've got questions, but I won't do questions.

Well, we'll see. Revocation is the last one. Three big revocation problems to watch out for. If the verifier has to contact the issuer to check revocation status, the issuer can figure out what the, that holder is doing.

Okay, so that's problem number one. And obviously that's a privacy issue. Problem number two, we just talked about unique revocation identifiers. We need to figure out how those are gonna work and not trigger any privacy issues.

And third, this one, privacy preserving revocation at scale is really, really hard. Drummond and I spent some awesome time writing for the Epsy guys, a study of different revocation mechanisms used across the world for all sorts of different credential types and and so on. And we need something that goes at massive scale with massive privacy and there's a bit of a gap there that needs to be filled.

Owen, that is extremely well proven as well. I'm amazed this is standing room guys, this is fantastic. I thought everyone would've literally be badly hungover or gone home, so, so that's six things to watch. And I'd like to, I, Mike, one more moment I'd like to add one other thing. Can I have a show of hands? All of those that are writing are specifying the user interface for the IDAs reference wallet. Okay.

So, oh, okay. User group. Who's your experience at tri? Yeah.

Okay, so here in Liza problem, right? If we said who's, who's involved in tech, in the wallet world, everyone stick their hands up and so on. There's a huge amount of work being done on legislation and a huge amount of work being done on technical protocols. There is no or very little work being done on the user interface. And if the user interface isn't brilliant and delightful and beautiful and easy to understand, it's not gonna work.

So my plea here to anyone who is influential here is get working on the user interface and give it the same or higher priority than the toolbox and the legislation. Apple's got it already, but play not, no. So thank you very much, Andrew. Thank you very much. Finished.

So, so I would like to take questions, but before I take questions, I'd just like to ask Andrew to give me a revocation list of all the people who are no longer entitled to ask questions. Oh Yeah, that's un now, Now this is a serious point because I, I'm, I'm old enough to remember when there was going to be a root of trust for the internet and nobody could pay afford it and nobody could pay for it. So we got a question. I dunno if you've heard of o open certificate Status protocol.

Ah, There we go. Yeah, There you are. So there's a question from the back, but I don't know whether I can get through Quiet at the door. We're having a conference here and we need to move on to the next presentation pronto as well.

Oh, you're, you're here, here cracky. Want to squeeze up so we can all fit in.

Right, Right. So the, the request is, can, can you all squeeze up so that you can all fit in, but please keep the front row free for the speakers. There's plenty of seats all around. So come in and go around the bank if you want Seats. I suppose you are, you are coming In, come around the back. Just blown.

Oh, we got a question. Hold on. Where's the mic? Mike?

Mike, can I have the mic? Sorry, go. There's a question. Everyone please respect the questionnaire. Shut up. Go ahead. Hi. Speaker 10 00:30:19 Hi. I've got a question about the type one, type two introduction. And while I understand the drive to try and create a lot of use cases, I'm wondering if it's got any side effects in terms of having a wallet that's part of the wallet that's maybe less secure or that interacts with a very secure wallet, your thought.

Yeah, that's a, that's a really good question. So this type one, type two, I guess you guys are gonna cover this in a second, right?

The, the, the, I think there's a lot of protocol confusion at the moment, which I'm hoping the next presentation is gonna sort out. So, so Elaine probably I'll leave it to the guys who actually know what they're talking about and we can swiftly move on to the next one.

Okay, thank you very much.