Verifiable Digital Credentials: Comparison of Characteristics, Capabilities and Standardization of Emerging Formats and Issuance Protocols

So our first, in our first track, in our first session of this track, we are glad to have here at the eac, Paul Ians and Hughes Andra and letter stand. So please join us to welcome them to our session. Feel free to start with your presentation.

No, we are much excited to sit down. So we, we, Perfect. So then we will begin with Andrew. Hello everyone in. Brilliant. My regrets for not being able to attend in person, but I'm sitting down Toton, so I'll do that for the, for the rest of you. So I'll ask you to advance the slides as I need them and let's get started. So let's move to the next slide. Hello everyone. My name is Andrew Hughes. I'm the director of identity standards at Ping Identity. Today we're gonna talk about digital credentials and issuance protocols. How Do we call the technical? They cannot present the slides.

Wait a second, Andrew. Okay, Clicker doesn't work yet. My slides are advancing on my local computer, if that helps. There we go. I pressed the button, so I don't know if it was me or someone else.

So, Okay, so This is a very interesting time in standardization for digital credentials. I'm not sure how many people in the audience are part of the standardization process, but it's standardization, especially with communication protocols and interoperability protocols. It's done by groups of people and as you know, people have different ideas, different experience and different outlooks on how things should work. In the end.

What we're gonna cover today in this, in this presentation is some give you some insight into some of the work going on around the world in different standards bodies, on digital credential standardization, and particularly on issuance standards. So I thought I'd start off with this, this little summary and overview slide. Just giving a, a general context for what, what a digital credential is. As you can see on the slide, digital credential conveys information that isn't an authentic representation of information held in a registry at the time of issuance.

That's the context of what we're talking about with digital credentials. It's from a database and it's authentic, an authentic representation. Now the packaging security and metadata of those digital credentials gives the recipient, the verifier, the relying party, the service provider, whatever you call them, gives 'em assurance and confidence that that digital credential is actually genuine. Put those together.

It's a genuine digital credential and it's an authentic representation of information with timestamps and you can, you can grasp the value of digital credentials going forward as we'll see in later slides. Digital credentials come in many shapes, types and formats. Andre will cover some of the work that he's, he's been involved in on cataloging and characterizing and examining the nature of the different standards for digital credentials. Next slide please.

So, issuance protocols. What are issuance protocols? I want you to keep in mind that during this session we're taking the point of view that the, the world of digital credentials will have an infinite number of possible wallets. People will create wallets to store digital credentials and issuers.

The many, many issuers of credentials will have to interact with any number of wallets. That's why there must be standards for the interaction between the issuer and the wallet. And it's these means to obtain a digital credential, place it in a wallet, and ensure that it's installed correctly. That's what we're calling the digital identity or digital credential issuance protocols.

You'll, you'll know them by different names and the different standardization bodies. You know, there's verifiable credentials, language, ISO language and so on. But as a general class, there are digital, digital credential issuance protocols. Next slide please.

Okay, so why are there so many standards? Standards, love standards and standardizers love standardizing, and I, I apologize for the quality of my jokes. It's early on the west coast of Canada this morning. So what we have is a tension between requirements. So remember from the top groups of people come together with their knowledge, experience, backgrounds, outlooks on how the ecosystem will evolve. And they try to figure out what requirements they must satisfy as they create the standard for the protocol Credential issuers have requirements.

Now, if you're talking in a government, high quality, high value, e i d or mobile passport or mobile driver's license kind of digital credential, the issuers really wanna make sure that they're secure, they're well protected at all times. Now they acknowledge that there might be some credentials in the world that require less protection, but they're gonna design for what they, what they require for their usage scenarios. So it's not a one size fit all scenario. On the other hand, software and hardware emerges based on the creators of that software and hardware.

So they examine what they believe the market requires out of their software and hardware. They have capabilities for design and techniques and development approach and they have to make trade offs for implementation. And at the end of the day, the wallet development team de determines what features go into digital wallets. So you have attention credential issuers want what they want because their business requires the level of security and assurance and reliability that it does. There's no changing that.

Then wallet providers have to build what they're able to provide and what they understand the market needs. In the standardization process, what you see is many groups of stakeholders with different sets of requirements that are often in conflict come together and try to figure out how to make it work together and make the compromises and trade offs as we go forward. Excuse me. Standards are developed in not only in groups of people but in organizations.

And you'll find as you explore to the standardization world that each standardization organization attracts different kinds of participants. So in the ISO world, we have, you know, a lot of government representation, smart card representation, you know, large issuers. That is a trend of the kinds of people in that standardization organization.

In other standards bodies, we have more wide scale ecosystem, broad use of digital credentials for issuance and wallets and everyone's got a different point of view, but we designed the requirements that we are aware of and we are able to, to meet the next slide. I wanna make sure I leave lots of time for the rest of the presenters. There's a good depth of information coming. So bottom line standardization reduces risk. Issuers want to have control.

Wallet providers want to have control by defining standards for the communication and and security features of of digital credentials and wallets. Credential issuers are able to exert some control and work in balance with the rest of the participants in the ecosystem to meet their needs. We want unlimited innovation for both issuers and wallet developers. That is the goal of the standards community as a whole. We want user choice, we want the right level of security, we want incredible features. We want each of the stakeholders to achieve what they need to do to get their work done.

There's trade offs, but standardization is a strong mechanism to achieve that. And as a whole, credential issues, protocols must accommodate all these different pressures and needs and stakeholders to be effective and and gain adoption. Next slide please. So what are we talking about in the session? There's a lot of work going on right now with issuance protocol standardization. We cannot tell you what will win the game in 10 years time. We cannot tell you who's gonna be around which standards are gonna be around in five years time.

What we can tell you is what we're aware of that people are working on today. There's meetings every day in different standards bodies, different work groups, writing the standards now implementing prototypes, test software into production. And they're changing. They're shifting what we're, what we're working towards as we we see with pretty much every communication protocol development is an explosion of possibility. We're in the that explosion of possibility stage right now.

In a year or two years, we'll start to narrow down to a coexistence of different approaches for different kinds of stakeholders. Then maybe in five to 10 years we'll start to see more convergence. And then at the end of 10 years, if it hasn't been rolled, replaced by another side of approaches, we'll see the consolidation down to the, the, the core protocols and core standards that everyone uses that are ubiquitous. If you examine every communication protocol, standardization effort over the years, it, they all have a similar pattern.

And we're right at the exciting early days where nobody knows whose ideas are best and whose ideas will win win the day. So sit back and enjoy. We're gonna give you overview of digital credential standards and capabilities. A look at some of the leading work in issuance, standard protocol standardization, and then dive deeper into wallet security because you know, issuers need these things to be so while providers are stepping out to give them what they need. And with that and the next slide, I will pass it on to Andre Kuda. Thank you. Thank you so much Andrew.

I'm Andre and I'm very happy that I can talk about this topic here today in this great audience. So that started up with a question who of you already has a verifiable credential?

Ah, that's a fair amount of people. That's good.

So, and do you know what type it is? Ah, not so many hands.

Okay, good then, then you're right here at the session. So this is going to be interesting, I hope. What are we trying to achieve here to bring clarity to the mysticism of verifi fiber credentials, data types and formats.

So, so we have approached this topic together as a community effort and this is a much larger group than is here on the stage right now to create a credential profile comparison matrix. Okay. Very complicated setup already, but you will see it is complicated. But that's exactly the reason why we did it. And all this work is accompanied by a guiding paper that is also published.

It's in the final stage right now and accompanied by a summary presentation that has basically all the condensed information in there and the paper is done, the matrix is working in progress and it'll continuously be work in progress because there will changes and be appreciative of that. So why have we done it? We heard about complexity and the potential for convergence. And this is in due time because the credential profiles have very strong follower communities.

You could say they are religious about their credential profile and for many good and obvious reasons, they are convinced their stack is favorable. But we said, we said we want to have a more objective and fact-based comparison, which is in our view long overdue. So with this work we have done here, we want to ensure we facilitate an objective discussion and comparison to allow for an educated decision taking by non-technical and also technical audiences. So how have we done that? We have created the comparison matrix, I'll come to that in a second.

It has six categories with 50 criteria that can be in a very complex combination. And we have engaged over time experts from different stakeholder groups, that's the broader community I was alluding to, engaged them to obtain their input. And we have done this throughout the past year and this one with a couple of milestones.

And this is also a good opportunity to talk about bridging communities and bridging the events and all the community activities that are happening because we kicked it off at one of the major events of the identity community at the I R W Internet Identity workshop last year in April. And we have continuously worked off of that to have a taskforce approach to drive this forward and engage the expert community. Then we engage with a different community, the reporting web of trust community and created a paper, which is the company guidance paper that we have created.

And this is also available now as an intro to this work. We then again touch base at the internet identity workshop.

And again, later on this year trust prior to this conference, we have completed the work there and the final review. So with all that, having that set, you may want to take a screenshot of this here, which is a link to the credential profile comparison matrix, which we will not go into full detail, but it's just too large to display here adequately. I will just show you the list of criteria which basically are on screen now. We have these different categories, credential format signing, algorithm revocation, algorithm key management and trust management.

And under these, all these 50 different categories criteria, sorry. And actually the complication is, it's a mixed and match kind of story. So you can basically combine the different types of formats and signing algorithms and so on. So the obvious insights are there are so many different formats out there, it's a zoo and it is a mess or was a mess. At least we think we have poor clarity. And the number of profiles that you can derive off of that is even higher because you can combine all these different categories and come up with yeah, a multiplication of possibilities.

What what we feel we have to achieved with this is a lot of clarity in this game. So no more religious debates and also a learning from our end. Not all the data items could be collected, however, it was already very useful to do some evaluation of the most common things that are discussed out there. And I just show you this slide to make you aware of some key criteria that we thought were very, very interesting and very, yeah, important to look at, to basically come to conclusions. What is something that can be mass adopted?

What is something that we can really use going forward at scale and make a useful landscape out there with an open ecosystem with wallets and credentials that work together and can scale and provide really utility to people who use them. So these are the the criteria categories we, we boil down to. You see selective disclosure and unlink ability, you see hardware security support, you may see that the yes and nos and unlink ability and north in unlikeability and hardware security support are the opposite. This is kind of a not so nice trait, but we'll come to that later in the, in the review.

Obviously we need post quantum save cryptography and crypto agility and all that good stuff. We obviously want to use standardization.

You, you heard Andrew already referring to that. So people of standardization and it's, it's warranted that we take that into account that we have a solid standardization body behind it that everyone likes and likes to reference. Technology readiness level is also interesting to look at and predicate support. Who of you knows what a predicate is?

Okay, yeah. First all guys, yeah, this is something very cool. So this is something very cool in fact, but this is something that the, the decentralized identity community usually called as the selling proposition that is so cool that you want to have ssi. So it means that you can basically disclose certain data with, without disclosing everything of it and even do something like a range proof, like saying numbers within a certain range that you can prove that you're in the salary range without disclosing the actual salary. Something like that.

And everyone likes that, loves to hear that and says, but where do we wanna apply it now? Hmm, I don't really know.

So, okay, let's park that for a sec as well. Semantic support is also something that is obviously very, very important. So we want to have interoperability along the, the different schemas that are out there and understand that and support this as a key cornerstone of the credential. So having looked at all that, probably some of you have your favorite on the, on this list or have had the favorite on this list I had at mine. I was an advocate of one of them. So those of you who know me probably can guess.

But with the work that we have done in the community, I think we have now arrived a really cool setup for scale. And if we look at this layered architecture model that we have, the credential layer, the protocol layer, and the key interest layer, we look at the protocol layer in a second. You see that we basically have managed to decide on, based on this analysis that we, we put in there that it is a good idea to do W three CVCs in the SD jot configuration and also ISO mdoc.

Yeah, that's a different story. I want, don't want to go into that now, but for the a f specification that you see on the credential layer here, this is what's in there right now. So the EU digital Identity wallet, which references the architecture and reference framework, basically has these in there. And I think this is very good because we have now clarity this is something that would be regulatory compliant to use as mass adoption at scale and all the other things may have good properties, but this is something we think is really cool to use going forward.

So with closing, I want to let you know what's happening else in 2023. Obviously we are all eager to basically promote all this work and get it going, get to production. So the the guys will also continue to present the work at the next occasion at universe in Las Vegas. And obviously many, many more occasions will come by presented. But I want to close this down with, this is a community effort. We have started as a loosely coupled team of people working on this together at the various events and occasions. And we want to continue this in a more project official type of style.

So we are finding a home for all this work in one of the standardization groups or one of the, one of the trust services groups that are out there. So we will find a home, most likely it'll go down to the open wallet foundation so that we have this as an architecture guideline for the work there. So this is what, what is coming next and please stay tuned if you are interested in that, get involved and yeah, please join the crowd and become part of this community driving this forward and bringing decentralized identity to mass adoption. Thank you. Thank you.

Hello, I'm Toon and along the architectural stack that Andrew just presented, I'm gonna talk about issuance's protocols because as you can see in that picture, decentralized identity is much more than just credential formats. I mean credential formats are a very exciting part of it and that's where we started our analysis. But basically to really issue credentials and to present them, you somehow need to communication protocols to either issue them from an issue to a wallet or present them from a wallet to the verifier. The way we approach that is, is is pretty similar, right?

So for example, we did a session at last, i i w talked about what are the different protocols and I mean you may have noticed there is sometimes tension, right between the different camps. And as Andrea pointed out, people are religious, sometimes religious about what they do. I would say they are passionate, right? And I really like to work with passionate people.

If they, even if they favor different technology then, then I, I myself favor and it's, it's, it's interesting what you can learn if you if you talk to, to those other crowds. So we have started to do the analysis for the protocols as well. And what I gonna do today is we don't, we don't do a in-depth analysis, but as Andrew pointed out, we wanna let you know what work we are aware of and I would like to, yeah, put a spotlight on the, on some of the characteristic features or unique features of the, of the different approaches.

The four candidates that I'm gonna talk about are DICOM or more, more specifically did DICOM issue credential protocol, open ID for verifi verify credential issuance, ISO 23 2 23. And when I'm done with that talk, you can all speak those numbers pretty quickly, right? Just we ask you to do so, so ISO 23, 20 20 dash three and we talk about VC api.

Alright, so let's start with DICOM issue credential protocol. So basically who have you used dicom? Alright, so DICOM is a, first of all is a generic message-based protocol. It's end-to-end secured, it's it's multi hub. So I typically compare DICOM to hdps, right? So if where you have HDPS for DI connections, for example to an A api, DICOM is something that builts on top of, of the basic messaging layer, but provides you with this end-to-end. So security. So it's highly secure and can be multi hop and based on dcom you can build other protocols, application protocols.

And there is one that's called issue credential protocol. There are different versions. This slide is based on the on, on the, on the, on the latest revision. And there are certain characteristics. So DICOM itself or DICOM applications heavily rely on verifiable credentials, for example, to to establish trust in in the other party that is on the other end of the communication layer. But you can obviously also use the same pr the same basic mechanism to issue credentials. The protocol itself is credential format agnostic.

I really like that because for those of of you that attended the session that I gave in the morning with Christina, we believe that's very important that the protocol is independent of the credential format. But cuz as we've learned there are so many of them, right? And you need some modularity in order to get structure in that chaos. DICOM also supports the field that's called batch issuance. And batch issuance mean you can in one transaction spit out multiple credentials, which is pretty, pretty useful in in some, in some situations.

For example, if you want to have one credential with different keys, which allows you to somehow cope with the linkability problem or if you wanna spit out, for example, two, two credentials with the same data but in different formats. For example, the E IDAs A R F requires issuers to issue a personal identity credential in two formats, mdoc and SD job. So an FEV batch credential can do that very, very efficiently. Regarding user experience, DICOM is designed in a way that all the communication goes through the wallet, meaning the issue itself for example, doesn't have a user interface.

And we see that's a big difference for example, between open ID for verifi entry issues and dicom because the communication protocol between the wallet and the issuer needs to be rich enough. So you can really send through everything that is needed to identify, authenticate, authorize that process. The specification is done at the decentralized identity foundation. Next on stage is open ID for verifi entry issuance. Design-wise it's pretty different. So DICOM is a messaging message based protocol, whereas open ID for verifi verify credential issues.

It's, it's an api. So who have you as familiar with o a little bit. You are a little, okay, I can, I can teach you afterwards if you want.

Alright, so o is is the defecto mechanism for protecting APIs. And, and the authors said, well let's do an API that can be used to request and, and create credentials.

So it it, it in the end leverages everything that has exists for oof. And as I pointed out, one characteristics of the protocol is that if you want to do the issuance, you can give the issue of screen control, which is a very powerful but sometimes neglected feature because it allows the issuer to either onboard the user or authenticate the user with whatever mechanism is needed. Whether this web off and username password or I don't know, it just works. It's also credential format agnostic and supports different security levels.

Meaning there are mechanisms in the protocol that you can use to do, for example, wallet attestation. If you wanna make sure you are talking really to a, a wallet that is, for example, certified under a certain regulatory regime or if you want to get approved that the key is stored in a certain kind of hardware security module.

It also has batch issuance and also mechanism called deferred issuance, which means if the process is, is performed, basically everything is set, but the issue needs more time because for example, there's really batch batch processing involved in some existing pre-existing system, then you can defer the issue and so the, the user can go, come back and pick up the credential a a day later or a week later or something like that. The specification is done at the open ID foundation and yeah, it's been adopted by the E I S V two radio regulation for online use cases.

The third candidate is the ISO specification. You remember ISO 23, 20 20 dash three. It reminds me of my first, i, my first session at the I TF meeting when I was so impressed that all the people there could really remember all those RFC numbers. Like RRC 67 49, which does not, did not exist at that time, right? So you get, you get used to that if you're a standardization nerd.

Alright, so ISO, the ISO specification is message based. So in contrast to open ID for vci, it's message based and it's talking about messages being exchanged between the wallet and the issue, which in this case is called the MDOC app and the AMDOC issuer, the issuance protocol itself is specific to the amdoc format. So the ISO standards, this standard as well as 18 or 13 dash five and dash seven only support the MDOC format, which is a binary seaboard based credential format. So you can only issue and present credentials in that format with that protocol.

It's definitely designed for high assurance credentials and issue controlled processes. And in this case really the issuer has a lot of control about the issue and so it can really refuse to issue a credential to an OC application that, for example, does not have the attestation for certain security characteristics. The protocol itself is extensible. So there's a base protocol to set up the connection and then there are embedded in that protocol multiple sub protocols, right? With previous versions there were six different basic six different issuance protocols.

They somehow trim that down to two of them. One is basic sa, which in my perception is pretty much or very similar to the way open ID for VCI works and the HP ke SA protocol is, is designed to allow the issuer to communicate with the so-called secure area on the, on the device of the user through the mdoc app. So it's, it's basically sending messages back and forth between those entities but mediated by the Mdoc app.

It's, I just told Paul it, it reminds me on the design of the, of the German SMART E I D system where for example the, the stuff is being issued into the SIM card or into a secure element. So we can do really high secure stuff with that. The ISO specification also supports open ID for verifi verify credential issuance to m to to issue mdoc, which is especially useful if you wanna do multiple credential formats. But I personally as an editor of Open ID for Visa, I find it's anyway useful.

Alright, so specification is done over there at iso. So let's now talk about the last candidate here, which is being developed in the W three C C CG group. It's a community group, not a standardization group, it's a restful API for managing the life cycle of verifiable credentials. It started as an API for setting up test data for verifi verify credentials and it also has issue and support in the meantime it has support for different roles. David Cheick touched open that in in his presentation today. It is Jason LD specific.

As I said, some people are religious about their credential formats and it is an obstruction within the party. So that means VC API is not intended to be used as a protocol between a wallet out there and an issuer if those are not entities run by the same party, right? So you would perhaps use that, use that API internally and that's the way the data to the block fest.

For example, you've got an issuer that issue internally uses VC API for modularizing, the access to the credential database and then you would put in top in front of that, for example, open a DFA VCI to do the external exposure of of what you have done. So that's hope gives you an overview and some feeling of what's going on in that space. And in a similar way as we do that for the credential format comparison, we are also trying and to yeah, build a information base for people that want to make decisions about implementing protocols. It's also metrics actually.

Yeah, the work is is is pretty early right now. We just started it at last I I w and and now there is a group establishing a, a trust over to work on that stuff. So if you want to contribute or just wanna listen, come by, help us to, to also evolve that work because I think that really helps to to, yeah, as Andrew pointed out to help decentralized identity, guess mass market adoption. Thanks a lot.

Yes, thanks Toten. Thanks Andre. Now that we know more about the credential formats and the various issuance protocols, in the last part I want to focus on how we enable the use cases for, for high use ca for high security or regulated environments and how we can extend the issuance protocols and which credential formats to use. What do we need to take care of in the regulated use cases before we step in? I would like to go one step back and say that the process that I'm gonna show now is not to be applied to all use cases.

In general, open identity ecosystems work so well and they thrive because there is a broad range of use cases that can be used within the same ecosystem because it can be quite beneficial to present multiple credentials. For example, a driving license and a credit card, or I can show my vaccination a certificate and a cinema ticket at the same time if they are coming from the same ecosystems. But some of those use cases have lower security requirements than others. For example, for a gym membership, I don't need as much security as an issuer compared to an E I D or a passport.

So the regulated and non-regulated issuers have quite different security requirements. And this was also addressed by the IDAs A R F, that's the architectural reference framework that was published earlier this year. And it gives the first out view which technical standards should be used in the IDAs 2.0. And they also saw this distinction between different requirements and they defined a type one configuration for high assurance use cases, especially for the P I D, which is like the personal identity data, which is equivalent to my national E I D card.

And this is usually hardware bound while most of the use cases will probably fall in a type two configuration, which is more open, more flexible, and it also enables backup and portability. So if we are in this type one configuration and we focus more on regulated use cases, we need more wall security and we need to apply the regulatory requirements and the wallet is only just one part of this to achieve a certain level of assurance, there's a whole bunch of requirements that we need to address. And this is for example, the identity proofing.

We need multifactor authentication, they need hardware, we need to look at revocation, we need to look at all the cryptographic algorithms and the key length and also the, the organization, the governance behind all of this. So the wall just is one part of this, but it is very important to achieve a certain level of assurance because the part that the wall takes is usually the protection against credential duplication. That means we need to avoid that credentials can be extracted and multiplied from a wallet. We need to protect against theft and we need to protect against impersonation.

And the challenge that we have is on the right diagram that there is different security mechanisms that are present in today's mobile phones. And so the market is kind of fragmented. We could put everything in a software key that has a very high market share, but then this has a very low security and the more we get into higher security regions, there are more fragmented mechanism. Trusted execution environments are kind of somewhere between software and hardware.

And then for example, we got secure enclaves and iOS, we got strong box and Google devices, we got secure elements and Samsung devices and all of these mechanisms have different form of attestations and how we can validate them. So all of this gets very complicated. And the three main things that we need for wallet security are listed here. The first one is device binding. So we need to bind a credential to a hardware back key. That's basically the, the requirement to, to achieve protection against credential duplication.

And this is also where we come back to the credential formats because we've seen that not every credential format fits for this because some credential formats do not have signature algorithms that are available in all of the security key stores. So this is 0.1, we need to bind the credentials to the user. So that's the user binding. The user needs to authenticate usually with pinard biome. So we know that the to protect impersonation.

And lastly, we need to have a kind of wall authentication that is needed so that the issuer knows that he is talking to a real legitimate and not manipulated a wallet and that he can trust that this user binding actually took place. Because usual user authentication is usually taking place locally inside the wallet and for a wallet at a station. We have looked into how can we combine these three main things into one model.

Don't be too afraid on this diagram because what you may be, yeah, recognize on the right side is of the usual triangle that we see in our issuer holder verifier ecosystem. And so what we need now additional, and we don't get around in it in regulated use cases, is that the wallet needs to be certified, it needs to go through an auditing process, a notification process. This is something that has to happen upfront and this certifies the software from the wallet implementer as a whole. And this will go, this information will go into a trust list.

And what we need for regulated use cases now if the issuer wants to issue a verifiable credential is that he gets a device at his adaptation from the wallet and therefore I step one the wallet will generate a hardware key, it will do an app at adaptation, it will do a key at adaptation and it will send all this information depending on which security mechanisms it's using to an at adaptation service and the at adaptation service, you can think of it like the backend component of the wallet and it can validate and check all these at adaptations.

So this is where the complexity happens of this fragment market. And if this is all valid in step two, the at adaptation service will issue an attestation.

We see, and this only contains the simplified information and not, not all the security chip specific attestation formats. The attestation we see will all only say this is wallet X, y, Z and it's using this type of security mechanism and the public key and which user authentication is happening. And then the wallet can prove, can can make a proof of this to the issuer and the issuer can check this information because he trusts the attestation service because it is in the trust list.

And given now this information, the issuer has checked all the boxes to be able to issue a regulated credential because it knows that is device burned. It, it knows that user authentication happened and he knows that he is talking to the legitimate wallet and he continue in his normal flow to issue a credential. We've discussed this process and designed that within the last one and a half years in the diff wall security group and inside the IDU in research project. And just three weeks ago at iw we've shown the first end-to-end issuance with wallet attestation.

So all of this is working in a demonstrator. I can show it to you after the presentation and we're ha very happy to have achieved this. So the summary with the wallet adaptation concept we've achieved to get interoperability in a very fragmented market of security and mobile devices. It's technology, technology independent and futureproof, it guarantees the best possible privacy for the holder. And we keep the complexity away from issuers and verifiers. We've demonstrated the whole concept with together with the LI wallet from ID Union and we as the OC issuer.

And this can enable the IDAs type one configurations. And the next steps is to bring this better into standardization. And we've actually achieved this with the health of Torson and the open ID for VCI protocols and the W three C selective disclosure Jots, if you want to get more information, I've written a white, white paper in the German journal called hmd. There's an English translation on the upper QR code. And if you want more information, there's also my slide deck from i w in the lower QR code. If I may, I would like Thank you so much. Thank you so much.

The presentation was very insightful. We have some questions online, but we would like to know if here in the, in the auditorium we have someone with some question to ask. We are happy to hand you a microphone. Is there any question here in the room?

No, not really. Okay, well, so then I, I wanted to add something, but is my mic on? No.

Yeah, okay. Just on the, on the topic that, that Paul presented. So in the morning at the, at the presentation of Open id, we mentioned that Open ID foundation and the working group is working on the high assurance profile, what we call an high assurance profile of open ID for VC with SD John.

And this, this high assurance profile will incorporate most of the, of the, of the concepts that you have learned in, in, in that, in that session. So including all the wallet attestation stuff and so on. So if you're interested in that space, want to build robust verifi build based systems, watch outer space and look for the high assurance profile for open ID for vc.

It's, it's coming up, it's just a matter of weeks. Thank you. Thank you for that. So then let's go with some questions that we have from our audience online. One of the question is, let's say that eventually there are two wallets. How does this affect the requirements, the wallets requirements? I think Andrew was talking about this at the beginning, if I'm not wrong. The question was what if there are two wallets? Yes. So it says, the presenter says that the, that eventually could be two wallets. How does it affect the wallet requirements?

Okay, basically we are assuming there will be a couple of wallets. I mean I'm assuming the European Union there will be 27 of them at least.

And that, that very much affects the requirements. Definitely, I mean, it makes it more, more important that the communication protocols and the, and the formats are being standardized and that the mechanism that is used to, to establish trust between the verifier and the wallet and the wallet and the issuer allows for third party managed mechanism for trust establishment. So no one can really, or a fire cannot really register with all those wallets right upfront. So there needs to be a mechanism in place.

Trust lists could be one of those mechanisms that's still a gap to be filled in the European union's IDAs regulation for example. But we are investigating that in IDA Union as well. Perfect, thank you so much.

Sorry, do you want to say something else? Andrew, do you Want say something?

Yeah, I think also we, we have to see how the market plays out with the number of available wallets. If we think about the mobile device ecosystem, we have two main design camps, design philosophies. We have the iOS and Android approach of controlled software stack, very, you know, high quality, high inspection, but very much according to the, the rules set down by the operating system. And we have Android, which is more accepting of third party software plugging into the system.

So hopefully we do not see the case where on one platform there's only one wallet, and on the other main platform there's a thousand wallets. Because the poorer people, me, you, we won't know what to do because it'll work differently no matter depending on what device we have. And issuers do not want that. We know that they tell us all the time, we don't have a solution as an industry yet, but we're trying to work on how we might resolve this difference of design approach. Thank you Andrew for that.

Yes, Andrea? I, I briefly chiming in from a user experience perspective, I think we will have many different wallets, but we have to have a seamless user experience for the user so that he's not looking through all his different wallets for the credential he just wants to use at this certain point.

So if I, if I may offer a vision here. So I think even if we have 15 different wallets on a, on a smartphone, if we want to have this good user experience, you have to basically have a, a way of accessing credentials that are under your control from every, from every wallet you have. So even if you have like an, an app that gives you credentials that allow you to access an event like this one, you may want to have an expert setting and say, this application can show me all the credentials that I have.

So I know this is a terrible from a technical standpoint to achieve, but if we are not making the user experience with the plurality of wallets a grade for the users, we will have a deal breaker. So I think this is something we as an industry and community need to work towards.

Yeah, in general I would like to add that. And usually we have kind of a triangle and that that's like security, privacy and user convenience. And as soon as we kind of lift one of those, the other ones will go the other way around. So at some point you have to decide if certain things, the user convenience is more important than privacy and we can shift around, but let, there will not be perfect solutions. Thank you. Thank you for your answers. There is another question here in terms of solutions as well.

How can individuals protect their privacy and control the use of their personal information when using verifier credentials? How can they protect their privacy?

Well, there's multiple different angles how privacy can be compromised. So I mean, the whole idea of decentralized identity is that you have more control over the data flows that are, are managing data items that are u to subject to use. So you basically control which data is going where, wh why are the means of the wallet. I mean this is the core idea of the thing, but you can, you have many different angles of compromising the privacy that comes with that.

I think we can have a whole dedicated session on that and maybe the others want to comment on particular aspects, but I think the whole paradigm of decentralized identity is to put the user in the core again to manage his own data And basically the protocols and the architectures need to be designed of privacy in mind, right? I mean it's a no-brainer. I think everyone should know that and I think we need to find out as the industry also what's the best architecture for, for really protecting the privacy.

I mean right now anyone is leaning toward, it's putting everything on the device because it's so sovereign. But in the end everyone also knows that putting any anything on a device is, is is the, the hardest to get secure design option because of the different mechanisms better cause of the, of, of malware on, on the device and so on. So we still need to learn, but we also keep, always need to keep in mind privacy is highest priority And to follow on torson.

So for people in the audience, I do most of my work in the ISO mobile driver's standardization work right now in ISO mobile driver's license work groups and crossover into the open 80 foundation, the ISO mdoc format is designed specifically to allow for selective disclosure so the user and the wallet in combination can determine what they will respond with. And using a pre-established technique, we can establish at the issuer side the ability to make a claim like over 21 or something like that.

So this mechanism's built in as part of the design, I know that all of the credential formats that are being worked on and all of the issuance protocols and all the presentation program PRO protocols have these concepts in mind and we're taking a few different approaches to try to achieve this ability to redact or constrain and make it the user's choice what to expose.

We'll we'll see which approach works best in the end, but right now the designers of the protocols and specifications are very, very well aware of, of the problem and we're trying to try and put the tools in place to, to address it. I'd also like to add that some people, and I think Victoria also mentioned it this morning, think that there is this kind of fear of over identification.

So if a fire requests my birth certificate for renting a bike and I can only get the bike if I click yes, this is a general problem that verifiable credentials and technology alone, no matter what credential type or issues protocol you use cannot solve, you cannot solve this over-identification by technology alone. And you need to put like the organizational matters and the laws together with technology so that you prevent over identification. But no technology alone will solve this problem.

Otherwise, Yes, here we cover well what is happening with the wallets when we add all our information on the mobiles. But another question is what are the ideas that you have in mind to protect cloud wallets for organizations? That's a good question.

So I think right now the focus on our work on wallet at a section was focused on mobile wallets because this is what I think most countries in the IDAs process are focusing on for organizational identities or organizations that want to have a wallet, it makes more sense to have a cloud wallet, but also they might have a a different requirements and that's, yeah, still topic of research, however that is also solvable. Maybe one comment on that.

So particularly in the large scale pilots of the U digital identity wallet, there's one of the consortium, the ewc, which is basically dealing with exactly this problem of organizational digital identity and organizational wallet. I think this is one of the really key topics as well because all the organizations who want to engage with decentralized identity and want to issue our verifiable credentials will have to have this, they will have to have either, if they want to send data to their users, they will have to have issuing capability.

If they want to digest data from verifiable, they will have to have the proof and verifiable capability and to store their own credentials. Yes, organizations will also have credentials. They will have to have their own wallet, which is like a multi-user accessible wallet. And this is, comes a lot of other complications for that. But this is an identity and access a challenge, which we, I think can solve. Right. All right. And as a closing statement, do you have any advice for companies that are implementing very credentials? Any other advice additional to to I just have one Advice.

Be pragmatic. Yes.

Yeah, I think yeah, use open source code. Don't try to reinvent the wheel and, and look if you can participate on open source initiatives, aim for interoperability. And also in the beginning, make sure what your requirements are before you just dive somewhere into, and then you are like heavily invested and don't wanna swap out again. And that's also part of the work that we, we did. So giving advice with these credential format metrics and, and issuance protocol metrics to, to help people coming into the market on like, yeah, which technology I should use.

Andrew, do you wanna go next? Sure. As an employee of a large IM and federation software provider who has decentralized identity products in the market, now work with your vendor as, as a purchaser on a corporate, on the corporate side. Make sure that your vendor has a solution that can adopt and can adapt and can be extended to the available credential formats and the protocols for presentation and issuance that you as a company need. There's lots and lots of ways to accomplish this.

So if you're unable to participate in the development of standards and open source, make sure that your vendor is to avoid vendor lock-in, allow swapping of components to go best of breed if you need to. And you know, companies like my company, our goal is to have everything that any customer asks for. It'll take some time. But that's our, that's our goal. I think we all stand for our different organizations and we are all very happy to help you to achieve your, your challenges with decentralized identity and, and, and get Hallmark applications out there.

So I think this is, this is, this is a good sign. We have a strong community already of, of, of people and vendors out there who can help you. That's kind of the one good message. The other good message is we have now the attention of everyone in the world on this topic. So just let's make it work together.

So I'm, I, I think with ida's 2.0, the EU digital identity wall, the a r f and all this good stuff out there, we have a massive opportunity to now make this a really cool ecosystem in at least in one big jurisdiction to get really production stuff out there, interoperable out there. So let's make this a great success story together. And this is to all of you, let's make it together because I think there is so much opportunity for everyone involved there. And I think with all this, having all that said, it's a marathon for all of us.

We have been in the game for HS felt like eight years plus or more, whatever. So I think now we have the attention of everyone, regulators throughout the world.

So let's, let's get it, let's get cracking. And I want to thank for, for all of the team here cooking a coal, for giving this topic, the prominence at this event this time on the big stage and in so many sessions with so many great speakers and contributors. So I think this is a great sign for everyone that this is now coming. Thank you so much.