Open Wallet Foundation (OWF) Guide to Safe Digital Wallet Selection

Thanks. Well, thanks for coming. So we're Daniel Gold, the head of the Open Wallet Foundation is upstairs. Part of that Open Wallet Foundation is, is what we're gonna talk about today for the Safe Wallet sig. And so between myself and, and Juliana, oh, we have the clicker here.

And so, yeah, so we'll, we only have less than 20 minutes, but why do we need safe wallets? We'll talk a bit about Juliana, we'll talk about what that the SIG is and how you could join what the key pillars of the Safe Wallet are, and then a, a discussion. And we'll go over what, what we're doing in with the Safe Wallet guide in, in this discussion. So here you go. So the first thing we're gonna start with is why do we need safe wallets? And I think we're all fairly aware of the fact that it's a hostile environment out there.

It doesn't really matter what the context of the wallet is, what the implementation model is, what the architecture is. We have in a significant attack surface and very, very sophisticated attack vectors. And it's necessary at this stage, especially with the acceleration of the development of wallets, open source wallets, that we start to bake in an understanding of what safe means for wallets. So the SIG is just that a community of interest within the Open Wallet Foundation. It's comprised, Dan will go through the list of those who've contributed to the effort so far.

But we're focused all very highly focused on safety considerations for wallets, for developers and product management managers. Principally, can we create guidance that's independent of architecture and use case? Can we rise above the implementation and create standardized or guidance that can be referenced over time? We're principally focused on four key pillars and we're decoupling them from the implementation. So it's an actually quite a really strong exercise in understanding what the foundations are for safety in the context of a wallet, independent of how it's implemented.

So our fee, four key pillars that we've identified, and we'll want feedback from everyone. Did we get this right? Do we need more our privacy, security, what we call supporting functions, which Dan will review, which are the functions the wallet must be able to support from other parties in an interaction, whether they be an issuer, a verifier, a relying party. And then finally, governance, which might seem a little bit weird in the context of safe wallets, but it's really a necessary component and hopefully will be clear in helping you to understand why. Okay.

And the next series of slides are the, the four key pillars starting with privacy. Oh, oh, I'm sorry, this is it.

Sorry, got outta sequence here. As Juliana said, this is a, an open organization with a lot of contributors. These are the folks that contributed to the document thus far. It's about 30 pages and we, it, it's ready for, for public review or other others review, and we'll get that on social media, the link to that. And then we, so apart from the, the members of the special interest group, we had, we already had some level of external reviewers, as you could see there.

The, the next slide is the first of the four pillars, privacy. So, you know, within the, the, the document, we could go into greater detail, but, you know, privacy, you know, we don't want to be able to be uniquely identified. This was a key tenant within the EW digital identity wallet.

You know, the, the linkability traceability, we don't want, not that the wallet could totally handle this on, on its own, but we don't want issue verifier collusion. We don't want phone home. So that the, a verifier would go back to the issuer to get any, any sort of detail.

You know, we want any transaction between issuer holder holder to verify, to be privacy enhanced data minimization, secure channel set up, things like that. And on the, on the wallet side, you know, notice and consent when we disclose information, we want to be able to consent to that and have some auditability of that, which Chris, which Juliana will talk about on the right we put, as an example, we'll only do it for privacy of, of the checklist.

So we, we try to distill all the verbiage into these check boxes so that for all the different sections, there's 10, currently 10 sections in the document. Each has its own checklist. And this is just an example of the privacy checklist. Okay? So from a security perspective, the first thing I'm gonna say about security is it's deep and it's hard in the context of wallets. It's also really challenging to try and balance user experience, positive user experience with strong security measures.

And so what we've tried to tackle here are two pieces I've, I've got up here for, for our discussion today, the considerations for security. But the other part of the security component within the guide is on trusted processes that are necessary to support safe interactions. Things like how do you mitigate risks for elevated privilege for, for malware, how do you mitigate issues associated with social engineering attacks and, and various other elements like that that are in the guide as well.

But for today, we've popped up or highlighted the security considerations that we are trying to reference from other really strong work that's out there in the industry standards, other guidance. We've deliberately referenced Diac component for their digital wallet, their risk conformance criteria, and their risk register associated with that.

So we're really trying as much as we can and invite all of you to help us understand if there are additional references we start to, we need to include in the guide that provides strong, clear referenceable and hopefully standard based security considerations.

So the first we we've tried to tackle in detail is security by design for developers to start to consider as they develop their wallet, as they're tackling their use cases, their architectures, that how are they dealing with their credential models, key management, et cetera, is can we start to bake in security by design at the onset when we project managers and software developers are looking at their wallets, can we start at that time to bake in the security considerations? And if that is the case, what does the guide need to do?

What can we do at the open wallet foundation to help support them? The next is an elevated kind of approach to security by design, which is secure by default, which takes it to the next level where the default implementation is the most secure implementation and there's less opportunity for configuration variances that lead might lead to security gaps. The next we're recommending software cons, security controls like NIST 853 or oas mobile application security verification standard. So N 853 is independent of implementation, meaning it is not mobile specific.

And OAS mobile application security as the, as the title suggests is, is mobile application specific. Both are really good if you're thinking about building a wallet, if you're advising on wallets, if you are going to consume a wallet as relying party, it's really important to understand the security controls and are they starting to align with some of these standards based guidance that are coming from these authoritative bodies. The next is the, my favorite term, the sbo. It's a software bill of material.

It's the laundry list of the libraries, all the components that make up the software for the wallet, again, independent of the implementation, but really critical, not only in the beginning of the wallet, but through its lifecycle as it continues to evolve in the industry and in the market, it's really necessary to have transparency on the components that are within that wallet through the SBO m. And the last is a software development, best practices and software assurance models. We raised NIST 828 2 18.

And again, oasp software assurance maturity models are Sam two really strong pieces of guidance in the context of software assurance. Has nothing to do with a wallet, but applying them in the context of wallet security elevates the security considerations and hopefully the likelihood of wallet adoption by high assurance or by relying parties that require risk mitigation in the adoption or consumption of wallets. Great.

And we, we include both. It doesn't have to be a mobile wallet of, of course it could be cloud wallet, but we try to cover all the bases as Juliana said. And so the third pillar, the supporting functions that Juliana mentioned, and the previous discussion here was about user authentication and like the EU digital identity wallet at authentication level high. One of the comments was, well, I wish I could have a, a biometric on on the, in in the mobile wallet that was that signed and provisioned by a government.

I was hoping to see the pi, the person identity data included biometric issued by the government. And that's how you get holder binding. I'm gonna talk about that tomorrow. But in the case of passports, IKO, the UN agency that, that writes the standards for passports in 1995, they said the best way to associate the authorized holder of this identity instrument to the, you know, to, you know, to the author the, the best way to associate this identity instrument to the authorized holder is through biometrics.

That's why in 1995 they introduced the e passport that had a cryptographically signed photo at issuance. That's how you bind I identity attributes to the holder. We separated wallet lock unlock. How do you just open up the wallet?

It, it's using authentication methods. But again, if you're unlocking a device using a biometric, then using, using the reference biometric from that was bound to you at issuance is the best way.

Now one, the audience and one of the members presenters was saying, oh, it has to be on the server side. Well maybe with the right security measures, if you know that the software running on the wallet was provisioned by a trusted entity and not muck with, then perhaps you could trust edge authentication using a, a trusted signed photo using trusted, signed software, then backup and restore.

This was a, a big a a big issue, especially for mobile wallets where if all your keys are including your private key on a, a mobile device and you lose it, or if you want back up and restore it, how's that done? If you're, if a private key can never leave its secure enclave, how do you, how do you back that up can be done, but we, it's a consideration. Right? And then credential management, same thing for the verifiable credentials that in that are in your wallet. How do we maintain those? The presentation protocols, again, the, this industry is very much evolving.

There's different ways open ID for VCP for, you know, verifiable, verifiable presentation, verifiable credential presentation and others. Some have, there's pros and cons.

So the, and that's detailed in the document and we need to have those as considerations. The key management, if I, if I have a wallet and I lose it and I signed a bunch of things with that private key, how do I manage that now the key rotation, things like that.

And then, oh, I already started talked about authentication, but I'll now for the fourth pillar, turn it back over to Juliana. Okay, so the last one on our, our laundry list here is governance, which might seem to be a bit weird in the context of security or safety for wallets. But what we're dealing with on the governance side for wallets is a technical and standards based implementation, the must be secure to solve some regulatory policy, policy compliance and risk-based challenges. So without safety on the wallets, the ability to mitigate risk-based challenges is pretty low.

So it's a necessary component from our perspective. And we've really tried to tackle that within the sig. And wallets are an interesting cat 'cause they sit at the confluence between what we would traditionally term as counterparties who engage in transactions. So my bank and their client, the doctor and their patient, the government and their constituent. And then we have relying parties who depend on that digital identity information from trusted sources to provide services.

So without safety and without governance over top of the safety, it's really going to be difficult to get true adoption to solve some of these risk and policy-based challenges that are, that the wallets are stuck in the middle of. And what is also a really critical consideration is the wallet is very likely to be subject to multiple requirements from both sides. The identity side and the relying party side. And I'll give you an example and we've listed out here regulatory compliance, auditability, accountability, attestation and certification.

So let's say we have a wallet with an EID in it, and then we're gonna add a payment credential to it instantly. Instantly. Now that wallet is subject to another form of certification, PCI, potentially some EMV components to it. New measure of authentication is required for PCI that may not have been considered by the, the identity wallet provider. How does that get managed from a security perspective?

It introduces new and more complex security controls that are necessary for compliance or it won't go in the air, it won't get adopted by the relying parties because they have to manage their risk on accepting a transaction from that wallet. And the, and they are likely on the hook from a liability perspective. So these are really strong considerations. There're things we're looking to explore within the context of this sig we are in flight, we are a fairly new group over what the last few months.

And we've done our best to lean in and put together a very strong list with a very strong, as you saw group of individuals. But we're looking for feedback. We're going to publish our first rev. We're looking for considerations for feedback from the community, lean into this thing. Let's see if we can start to create a referenceable guide that starts to apply for safety around the world, each region around the world. Each technical architecture should be able to grab key references in here for and security considerations, safety considerations, privacy considerations moving forward.

So it's gonna be a living evolving document and, and we're looking for your help. Yes, thanks. And and that's, that wraps it up. This is a link to the, to the general page, right?

Yeah, the open wallet foundation page. This sig we have a, a GitHub page, but this will get you to the, to the top.

But yeah, if there, are there any questions for us? We have a couple minutes left. Minute and a half left. Any questions? One? Okay. How are you addressing equity considerations for marginalized groups and access to certified wallets and things that comply with all of the, the wonderful and important security aspects that we were just talking about may put some implementations out of reach for certain marginalized communities. So how are you guys dealing with the equity considerations of that?

Well, that's a incredible point and a great question. I think we haven't taken that into consideration at this point in time. We are simply trying to start to get to some structure and be independent of architecture. I think as we advance the effort, we'll start to have elements or revs of the guide that start to address specific implementations and challenges that different communities, different entities start to have in the context of wallets. But to the answer your question, we haven't even gotten there yet. We are just starting this process.

Yeah, I would just add, I agree with what Juliana said. I mean, but, and that's one of the reasons why I said it, it could be a, a cloud-based wallet. It could be a custodial wallet, you know, that maybe an organization, an aid agency manages and, and makes it so that only the individual can have access to their data and still be in control of it, but in a, in a a custodial fashion. Okay.

We have, let's do just Tell you a question just quick. How can trust over IP help in preparing this document, especially on the governance side? Thank you.

Well, one of the things that's gonna be interesting is taxonomy, ensuring that we have common language, common terms across the world. That's going to be one of the first things that after we get the first cut of the n rev of this draft out is the taxonomy. Are the terms consistent regionally and do we need to make some, some a glossary? I know trust over IP has foundations for that, so that'll be an interesting thing for us to explore. Okay. Thanks for your questions and thank you especially to Daniel and sorry, Daniel and Juliana. Thank you.