Bridging Digital and Physical: Making Identifiers Identify (Presentation to DIF)

Talk about today is bridging digital and physical to make identifiers identify. I'll explain what that means in a second. My name is Aidan McCarty. I run a company called UnumID. This has almost nothing to do with UnumID. It's not a sales pitch at all. It's a kind of a technical topic. It's kind of an advocacy topic, as you'll see. I think we need community action on this. So I want to start with asking, do identifiers identify in the first place? Which seems like kind of an odd question. And the answer to it seems like a truism.

I'm sorry, Liam, could I quickly interrupt you? Just wondering, your first slide said confidential and proprietary.

Oh, yeah, I should have taken that out. Scratch that.

OK, so just to confirm, you're fine with this being recorded and also shared and watched?

Absolutely.

OK, great.

It's a template slide. My mistake.

Okay, sorry for interrupting.

Oh no, thanks for asking. So the answer to this question is pretty obviously that an identifier is only useful if it identifies, and that's less clear than you might think it would be. So for an example of this, you know, one way to look at why is digital identity hard is the uniqueness problem. Offline, so to speak, uniqueness is Taken for granted, there's only one me. I have built-in private keys, so to speak, in the form of biometrics and behaviors. I am my own wallet. I carry those around in my person, and there's only one of me. No one is worried that someone might have cloned me, the physical person. But online in cyberspace, that's not the case. It's very easy to clone digital forms of me. Private keys are unwieldy. You have to put them somewhere. The question is, what is the wallet? How does it work? And so achieving uniqueness is a difficult technical problem in digital space. Now, of course, you've seen this problem before. That's what blockchain was invented for. In the case of Bitcoin, it solves the double spending problem, which you could look at as a duplicate tokens problem or a duplicate transactions problem. And in identity, there's a similar problem that I call the cloning problem. How do you prevent duplicate identities? The problem is that with identity, it goes one step beyond that. In the case of currency, it's enough to achieve uniqueness. There's on purpose no tie between any Bitcoin token and an actual real-world asset. That's the whole value of the currency is that it's not tied to physical assets. Otherwise, it would just be bartering all over again. But in identity, you want those identifiers, those unique tokens to identify things, whether it's objects or people, whether digital or physical. You have some identifier, you need to make an association between that and the thing that you want to identify. To take a recent example, we're hearing a lot these days about NFTs. NFTs, or non-fungible tokens, are meant to uniquely identify things in the world, whether they're digital or physical. But the question is, do they really? People in some sense said, well, we don't want to trust central authorities to tell us which collectible is which. Here we have NFTs, we can solve that problem. The problem is who's to say a particular token identifies a particular collectible? Cryptography alone can't do that because paintings and pixels don't store private keys. There still has to be some authority that says which token corresponds to which collectible, that makes that association between the two. NFTs and blockchains more generally solve the uniqueness problem in a very effective way, but they don't necessarily solve the association problem. And for identity, that matters a lot. If you think of it from a fraudster's perspective, the fact that there are NFTs for an art market doesn't really change much. You simply have to corrupt whatever authority is making the association between the NFT and the painting. It's the same fundamental situation as if the central authority was making the identifiers themselves. So this can— this is what I would call the kicking the can down the road strategy. It doesn't really solve the core problem because you don't have this strong association. And it turns out that especially for people, making identifiers identify, making this association is very, very difficult. Now, our approach, and I think many entities' approach to this, is pretty straightforward. It's a way of avoiding passwords and shared secrets and so on. It's cryptography plus biometrics at a high level. Now the cryptography part is, I think, a long way from being accessible to normal people. So the goal is to try to hide it. I did this fun Google search where I just looked up public key cryptography on Google Images. And the images, I think, speak to the fact that this is not intuitive at all. Unless you're an expert, you don't know what this means. There's no gist that a layperson would understand. Of what this is all about. And so it has to be hidden behind the scenes for widespread adoption. There's really no alternative. Now what we use here is cryptography to relate some sort of online identity or data to a device, and then biometrics to relate that device to a person. And if you use this in the right way, you can make a one-to-one connection between an identity online and a person offline. And that's really the fundamental goal of What we're doing, and I think what a lot of people are doing, is trying to create one identity online for each human offline. How do you solve that association problem? Now, there are different kinds of biometrics. I could get into the weeds on that, but the, the core goal is if you can do this consistently over time, now you have real valuable identifiers because they really do identify actual individual people. But there's a big difference between what's possible on mobile and what's possible on web, and that's really what I want to get to. Alan, I see you have a question here.

Uh, yeah, uh, just one quick question. I mean, today we know that there's both like online KYC or like in-person KYC, and we also have, uh, electronic, uh, identities. I mean, or these eID cards, meaning that at least in some countries, there are processes where they do this, of course, manually or offline. Is there any relation between— because so there are association models already today. How easy or hard is to use that device? It's another question, but is this related somehow? Or how do you see this part?

Yeah, no, there are many, many possible ways of creating an association. So to your point, you can use eKYC solutions or any number of biometric options. This previous slide that I didn't really touch on is talking about the difference between different types of biometrics. So the one we focus on that I think are more secure are device biometrics, meaning that they're evaluated locally in the secure hardware of a user's device. and the application only receives a binary answer as to whether that was accurate. It's different from cloud-evaluated biometrics, like say voice recognition for your bank, where there's transmission and evaluation of sensitive data off the device. That has a lot more flexibility because you don't depend on the infrastructure of the device, but it also has a lot more vulnerability because it's processing that data remotely and it can be spoofed much more easily. So for example, voice recognition is a big topic today. The vision is, hey, I call into my bank and they just know that it's me from the sound of my voice. And that sounds really attractive because you look at these machine learning models for voice recognition, they seem incredibly powerful. They are. But within 10 minutes of researching, you realize that the voice synthesis machine learning models are just as powerful. So there's this arms race dynamic there that makes the biometrics alone quite difficult to rely on. So the huge benefit of having cryptography as a core component here is that you have a private key stored in hardware on a particular device, and then you're relating that device back to a person. That's much, much harder to spoof because it's fundamentally physical, like it's tying back to the physical device. There's still that extra leg where you have to bridge that back to the same person, but the value is that you're not exposed to the same kind of large-scale remote attacks where you can try to compromise a million devices at once. In some sense, you can think of it as if someone held me at gunpoint and said, do Face ID to unlock your phone, I would do it. But you can't do that from halfway around the world to a million people at the same time. It requires physical access to the device. For things like the eID cards that you talked about, that's absolutely an approach. I think it's a great approach. The problem is that you have to distribute those cards and get people to use them. Some countries are doing that, I think, quite effectively. I'm in the United States. That's definitely not happening here, and there's no roadmap to do that, certainly within government at least. And I don't see it at all in the private sector either. There's a cost-prohibition problem where it's just simply expensive to get people all these things, whether it's a hardware wallet, like a USB drive, or a smart card. And there's also political barriers and all kinds of other things preventing that from happening. The goal of what we're trying to do, and I think what many people working in decentralized identity that I talk to at least are trying to do, is say, well, look, you already have your phone. Why can't your phone do that? That's the piece of hardware that you carry around with you everywhere. That should be your identity. But there are some challenges that are inhibiting that that I'll talk about. And the goal of this is to propose a solution that we can all act on.

Okay, thank you very much for— it's a very clear answer. Thanks.

Great. So I want to talk about the difference between what's possible on mobile and web today. On mobile, using cryptography and biometrics in the way I described is very straightforward. Ever since roughly iPhone 6 and onward, almost all modern smartphones, whether iOS or Android, have secure hardware elements. Pieces of hardware embedded in the device, and they have OS-level functions for cryptography and device locally evaluated biometrics, like Face ID, for example. An app developer only needs a handful of lines of code to leverage this modern infrastructure. So this is, I think, common knowledge at this point, but pretty much everyone has a phone, especially in certain countries. Like, again, I'm in the US. Basically everyone has a phone. At this point, since iPhone 6 was a long time ago, relatively speaking in the terms of technology, pretty much everyone has access to this infrastructure. We see this as very much an infrastructure change. So you can tap into this infrastructure to do things with cryptography and biometrics that you couldn't before. It's a boon for digital identity solutions. But unfortunately, on the web, it's a completely different situation. Web apps don't have access to any of the key features of mobile hardware and OSs. So for example, web apps can't do cryptography in general tied to the hardware. This means that private keys must be created and stored in the browser where they're vulnerable to loss and theft and where they'll ultimately be deleted according to browser caching policies. Uh, web apps can't do biometrics tied to the hardware either. This means that cloud biometrics have to be used, and these are less secure. They require high-friction onboarding steps. One way to think of this is Face ID I already did onboarding for because I set up my device. So an application doesn't have to make me do that again. Whereas for a new cloud-based biometric, they do have to onboard me, which is a barrier to adoption. And web apps also can't typically access Keychain or Keystore, the secure storage options for important app secrets. This again means that the secrets must be stored insecurely in the browser or in the user's head where it's likely to be lost, stolen, or forgotten. Now there are a couple small exceptions to this, which I'll address in a second, but the broad strokes situation here is that mobile has all of the core infrastructure needed for really great decentralized identity solutions. Web does not. Now, why does this matter? You might think, well, who cares? Why don't you just use mobile? Everyone has a phone. It matters because mobile adoption is really, really hard. I have come across a lot of people who are new to decentralized identity over the years, as I'm sure all of you have. I was one of them once. And their first instinct, as mine was, is there should be a dedicated mobile app wallet. That's the solution. We just build an app. Make it the best possible wallet ever, everyone will use it, and problem solved. Which, you know, at some point you realize it's just not going to work because it's very difficult to get people to install a new app, especially one that they're not familiar with, especially one that they don't understand the benefits of. So the big difference between mobile apps and web apps is that mobile apps require installation. They have to, you know, The user has to go through a number of steps to actually install it on their device, and they can delete it from that device. A web app is a URL. You can scan a QR code, click a button, it just opens in a browser and it works. So there's a big advantage that web apps have over mobile apps in terms of adoption. Now, there are some alternatives. Instead of a dedicated mobile app, you could say, well, we're going to build a mobile SDK that other apps can embed. We provide that ourselves at UnumID. It's a good solution, very powerful, but what you find is that convincing other companies to embed a mobile SDK isn't really that much easier than convincing users to install a dedicated mobile app. It's a different challenge, but it's similarly difficult to overcome. You can also try to get phone manufacturers to pre-install a mobile app on users' devices. One of our investors is Samsung. We've talked to them about this. We actually made some headway, but as you might imagine, they This also turns out to be extremely difficult. How do you convince Apple, Samsung, et cetera, to pre-install an identity app that you have some influence over on the devices? You can also try, to Alan's question earlier, to get people to use some sort of hardware wallet, some sort of external hardware. This could be a smart card like you were mentioning. It could also be a Ledger hardware wallet like I have on the screen here. Something that's external. But the problem is it's very cost prohibitive. It— users are not used to this at all. And so there's a huge adoption problem with how do you get people to be comfortable with using these sorts of things. In some ways, this has always surprised me a bit. You know, I use keys to enter my house, to enter my car, to do everything. And yet, for some reason, I think of it as a burden to use a key to get into my computer or my phone. That's just the path dependence of the way the world has developed. So we have to deal with that. Now, why is there this difference? It's actually a bit unclear to me why this difference persists. Why is it that web apps can't use the same mobile infrastructure that mobile apps can? Web apps can be run on a mobile browser. So what's the deal here? Why is there this difference? But there are several possible reasons, and I have good evidence for at least a couple of these. One possible reason: browsers are concerned that private keys stored in hardware can be used as persistent identifiers violating privacy requirements. The term super cookies is something I've heard used. I don't personally think this is that convincing. Mobile apps already have access to this sort of cryptography, so if there is such a super cookie problem, it certainly already exists in mobile. But also, I think there are ways around this. There are ways of giving users the ability to delete private keys that they've created. Uh, there are approaches that you can take to mitigate the privacy concerns of this, but that is definitely something that I've heard. A second problem is a potential conflict of interest. The main web browser developers, Google and Apple, also have mobile app stores. They charge hefty commissions on mobile apps and have no ability to do the same for web apps. So they're strongly incentivized to maintain this lack of parity between mobile and web. Because if web apps could do everything mobile apps could do, why would a developer build a mobile app and lose 30% of their profits to Apple when they could just do it on the web? So there's some conflict of interest problem potentially there. And then the third reason is just that the web standard communities that are organizing browser efforts around cryptography haven't seen enough interest in this. So I'll show you a couple examples of this. Uh, there is— there was a hardware-based secure services community group in W3C, uh, that was fairly active for a while but died about 5 years ago. You can see August 29th, 2016, the last activity on this. The goal was very much to create hardware-backed crypto for web apps accessible through the browser. But it kind of died off. And what I've heard from people in those communities is there just didn't seem to be enough interest in this. And so it lost steam. The other thing seems to be that the community leaders in the W3C specs that might do this are not particularly focused on Web3 or decentralized applications. And I think probably everyone on the call here has— fairly involved in notions of Web3 and certainly decentralized identity. And of course, any such application uses public key cryptography as a foundational component. Everything depends on private keys, public keys. And so it makes sense from the perspective of a Web3-focused developer or decentralized application-focused developer to care a lot about public key crypto. But traditional web is not really based around that. And so it seems that the people who are leaders in these community groups working on standards are not really focused on Web3. Whereas from the perspective of Web3, it's sort of baffling why isn't more focus on making this cryptography available to web apps, because it would open the floodgates to all these decentralized applications that have had a hard time getting adoption. Now, there is one exception. WebAuthn, and I'll tell you a little bit about that now. WebAuthn is the spec. It's a W3C spec. Uh, what it does is it enables one narrow use case for which web apps have access to cryptography and device biometrics, and that is authentication. So this is what the WebAuthn W3C spec prescribes And it finally achieved adoption and implementation by all major web browsers last summer. Apple was the holdout, as it often is, but last summer finally said, okay, we're on board with WebAuthn. They implemented it in Safari, and as is so often the case with Apple, now their implementation is way better than all the other browsers already. How it works is pretty simple. There's a notion of a relying party, which you can think of as a service or a web app. Like some sort of server, and that generates a random challenge. It sends it to the client, and the client uses a WebAuthn browser API to cryptographically sign that random challenge with a private key that's stored in secure hardware of the device. And that signature is gated by the user passing a device biometric check. So this is amazing. This is hardware-backed cryptographic signatures on the web mediated by device biometrics. Exactly the missing piece that I was talking about. You know, if you could do this on the web, so much is possible. But to date, it hasn't been possible except recently for this very, very, very narrow use case. But there's a catch. This is web authentication only, which means that the signature can only be used for authentication, that is, for signing random challenges. Now, this is extremely puzzling and frustrating from the perspective of decentralized identity and decentralized apps more broadly, because what we need is general cryptographic signatures backed by hardware. We need to sign presentations of credentials, arbitrary data packets. That's what we want. But for some reason, WebAuthn does not support that. It's sort of a prisoner of its own unfortunate name. WebAuthn says authentication. That's what it's about. It's not about more general cryptography. What's even more frustrating is that there's another specification, WebCrypto, or Web Cryptography, another W3C spec that enables very general cryptography that has very high similarity to what's available to mobile apps, but for web apps. However, none of it is hardware-backed. None of this ties back to the secure hardware of users' devices. It sounds great, web crypto. It sounds like exactly what a decentralized application would need, except that a decentralized application depends on public key crypto. With web crypto APIs, the private keys, they're stored in the browser, where they're not very secure and they're going to be erased. As the worst offender, Safari erases all browser storage after 1 week of inactivity. So you can generate and store a private key, but it'll be erased if the user doesn't interact with it in a week. This makes it essentially impossible to provide a good wallet-type application on the web with the Web Cryptography API because it's just not built for that. So what we need is the combination of these two things. We need general hardware-backed cryptographic signatures on the web so that we can build these sorts of applications on the web so that users don't have to go install a whole new mobile app they don't understand. They can just use it from a URL right away. That's the dream. So hopefully that makes sense as to why the problem exists, uh, some of the challenges and some of these strange ironies here. The question is, what do we do about it? And what I'm saying is we need to act as a community. We need to raise our voices a little bit. So I've tried to do this. I made proposals in the GitHub issues threads for WebAuthn. Here's the one here. I'm certainly not Heisenberg, a physics background, hence the cheesy name. And then WebCrypto as well. I haven't really gotten any— I haven't gotten very far with these. This one is technically still open, but there was some pushback that I tried to respond to. This one was closed. Primarily because Web Authentication is focused on authentication, more than that. So I have tried to speak up about this and try to get community action. There are a couple other people who have commented on these threads who are clearly also frustrated, who want general hardware-backed crypto signatures. So what I'm proposing here is that if you agree with me, if you think that having this functionality would be a big deal, if you you think this would help. If you think that having parity between mobile apps and web apps in terms of cryptography and device biometrics would be helpful to decentralized identity, as I certainly think it would be, speak up. Comment on these threads. Let's push the standards groups forward on this because I think there's enormous value to unlock by having this functionality. It's tantalizingly close to available. The fact that it's already available for a narrow use case with WebAuthn means that it would not be technically hard at all to expand to more general usage. The problem is not really technical at this point. It's about community action. It's about advocacy. It's about inertia. So what I'm proposing here is that if you agree with this thesis, let's act together to try to push this forward. Now, the thing that I've always admired the most about W3C, DIDF, and all such community groups is the acknowledgement that community action is just as foundational as technology. These are not just technical questions we're dealing with when it's decentralized identity. It's also community action problems. And so in the spirit of that, I'm presenting this today as a call to action that we need more people to speak up, to push this forward, to try to get this functionality available on the web so that we can do decentralized identity in a way that people can adopt more easily. Thank you. Alan, I see you have another question.

Yeah, okay. Well, it's certainly very interesting. I have a question with regards to web authentication. Is it possible in like 1 or 2 minutes explain how browser and— so where are Where were the actual keys for signing stored, uh, and how browser and that device— because I see there's a support for FIDO, so do you maybe know how this works in more detail?

Yeah, so WebAuthn is a standard that is part of FIDO, so it's not separate from that. Um, FIDO was originally developed for roaming authenticators. So things like YubiKeys, you might plug in external hardware that you would use to authenticate. And WebAuthn was an effort just to provide the same kind of functionality but with platform authenticators, ones that are built into your phone, to your computer, the Touch ID on your Mac, the Face ID on your iPhone, the face recognition on your Android device, whatever it may be. So that was the purpose of WebAuthn. Keys in that case are stored in the secure hardware of the device with the platform authenticator. So to just— I've been using an iPhone example, so I'll use that example still. Yeah, sorry.

Oh yeah, okay, now, okay, now it's clear. So if the, if the, if the hardware secure device is— so, so we are talking, we are not talking about cross-device interaction, we are just talking about, uh, So web authentication is about having something on the device and then talking to another web application in the browser or application on the platform.

Okay, so just give you a very simple example. Let's say you're a web app called Acme and you want to let the user log in. You, from the user's perspective, what happens is you click a button, you are prompted to do Face ID on your phone and you do that and you're logged in. So it's authentication but using the device metrics and hardware baked into the device that you're on.

Okay, then I at least I have a feeling because so having a cross-device interaction, so it's all fine, but having cross-device interaction really complicates things. So here's a question whether or not there's a way to establish the cross-device because the browsers don't have, cannot create that. There's no like permanent browser ID, right? This is, I believe, at least from what I worked on so far in the past, this was the main issue. If you find a solution to this, I mean, if there's a solution, to this issue? Yeah, the problem is solvable otherwise.

Yeah, no, it's a great question. There are solutions. Um, it's really a user experience kind of solution. So, uh, for example, in our case, we route everyone back through the phone. Now, over time, you can make associations between the phone and other devices. So as one example, let's say I'm using something on my computer, like a web app on my computer browser. To authenticate, I am asked to pull out my phone, scan something, and do the about then authentication on that device. For example, I can do that again the second time, or the second time I can do a platform authenticator on my actual computer, and now there can be made an association between those two devices. So it's a little complicated to describe in detail, but the basic idea is that you route everything through the phone because that's— the phone is the device everyone has that has this capability. And so that's where you route them through. It's kind of akin to an authenticator app, sort of, but it's not done with a mobile app.

Yeah, okay, okay. I mean, yeah, this, at least to me, this is clear. But, uh, yeah, there are still some issues that I'm not sure if they're resolved. Like, uh, uh, when you transfer information from the browser to the mobile, there's a high probability— I mean, there's still this, uh, phishing issue, because if you scan some— I mean This transfer from the device to the mobile is also— if you don't do it at least in two steps, like either you type something from your phone, like— I'm not— but we can discuss the details.

Yeah, there are a lot of tricky little problems. There are also solutions to those problems, honestly. They're not necessarily easy. Solutions, but they do exist. So you're getting at really good points. But the fundamental thing I'm highlighting today is that that sort of hardware-backed cryptography is available through WebAuthn for authentication. For some reason, it's not available for cryptographic signatures for any other use case, which is very frustrating because if it were, it opens up a lot more functionality. Anyone else have any other questions? Do you agree, disagree, thoughts on this?

So I also, also had a few questions. First of all, thanks a lot, Liam. This was really interesting. I think I also I liked your slides. They're very, very pretty. And I like your call for community action. So thanks for all of that. My main question is, I think— so I assume you're not opposed to people having multiple identifiers, pseudonyms, PRIs, DIDs. By the way, I also liked how in the presentation you didn't mention DIDs, right? It was not specific to it. That, that specific identifier technology that everyone is using, but you make it more, more generic. I like that too. But, but so I— when you started the presentation, I, I thought what you were going to talk about was having, having a single unique identifier for something like it is with NFTs, right? Or when you were talking about we as physical beings, we are our own wallet and we have our own biometric identifiers or private keys built in. And then you were talking about the bank example with voice recognition where you're sort of uniquely identified and you're having a, you have a single identifier. But I assume your vision is not that this is the only thing that will happen, right? You're still probably Not opposed to people having multiple identifiers, multiple private keys on their hardware?

Not at all. Not opposed to that at all. So I can actually pull up a slide that I had up before. And this sort of hints at that. So this notion of one identity is an abstraction. This is not to say you can't have many accounts, many pseudonyms, to use your term. Over here, you share different things with different people. But also, and this is the part that's less explicit on the slide, absolutely you could have multiple identifiers. I think pairwise unique is important. It's not to say that everything routes back to one thing that tracks globally and all this. It's more to say, at the end of the day, whatever identifier you're using to share with whatever verifier is requesting stuff, it should ultimately resolve back to a single human being. Now that doesn't mean that verifier A and verifier B should be able to compare notes and figure out who that single human being is, but it does need to relate back to that person to be reliable. So you can have the privacy-preserving pairwise unique DIDs, for example, as one technology there, but you also want it to resolve back to a person. Person at the end of the day. So it's definitely not at all opposed to having multiple identifiers. Right.

But you could also use biometrics in a way that where you have just one, like this voice recognition example, when you call the bank, if you choose to do that as an individual to reveal your single globally unique identifier, You could.

I'm not personally in favor of those kinds of approaches. One reason is that any biometric is subject to an arms race dynamic where, like I talked about with voice recognition, there's a voice synthesis other side of that coin, which means that the technology that develops voice recognition in many ways advances voice synthesis. Undercutting itself. Similarly, any biometric that you might think of, there are ways to defeat it. No biometric is ever perfect, and so there's going to be an evolution over time where things phase in and phase out depending on what works. And we're seeing that right now. They probably aren't right. Nothing's ever the right size. Tom, Jay, are you— I don't know if you're talking to us, or if you're not, can you just go on mute?

See, this is too damn long. Hey, Tom, are you on?

Hey, Tom, could you go on mute? I'll just continue. Anyway, there will be, I think, different types of biometrics will be good at different Right now, things like facial recognition are all the rage. I wouldn't be surprised at all in 5 years that we're not a good option because now the technique to defeat face recognition is good enough. So all I'm saying is that I think trying to resolve to globally unique identifiers based on biometrics is not a good idea because of this arms race dynamic and because biometrics are not really private keys. They're kind of public. Your face is not private. It's very public. So I think there's a problem with that. That's why I much prefer the locally evaluated device biometrics and an approach that is flexible to accommodating different ones over time and even combinations of multiple of them.

Yeah, that makes sense. So thanks for clarifying. I think there also use cases for having single unique identifiers, you know, voting or things like that. I think there have been a few discussions or community calls about things like proof of personhood or to prove that here's just, here's one of your identifiers and you don't have another one, right? You can't show up a second time. And people, I think, are also using biometrics for, for that sort of thing. But I agree with the downsides you mentioned, and I agree that, that locally applied biometrics tool to protect your private keys in, in a hardware device, that's, that's the more secure and more, more interesting use case, maybe. So, yeah, that was my main question. Thanks for clarifying that.

Yeah, for sure. I think the— you know, there are different needs for different applications, obviously. Like, some of— some applications don't need to have uniqueness of person necessarily. Maybe they only need proof of personhood, you know, you're not a bot kind of thing. But I think most of the more powerful applications require some notion of human identity over time. That's what's really hard. The technology part of this, or rather the cryptography part of this, is well established at this point. It's hard to get adoption. It's hard to actually deploy the systems, sure, but the notion of there are private keys and there are public keys registered and you can prove ownership over a private key on this is well established. The problem is how do you associate that with an actual person? Over time consistently. So I think that's a gap currently that I'm hoping things like better web standards that give web apps access to the new infrastructure of secure hardware will help close that gap. And if we can close that gap, I think decentralized identity will become a lot more possible for everyday people around the world to adopt.

Yeah, um, another W3C community work item that comes to mind when— while you were talking about this is, uh, CHAPI, right? The Credential Handler API, which is a web-based API for credential wallets where you can store and then present wallets. And for that, just like you said, you need to sign other things than just just an authentication challenge as it is in WebAuthn. You need to sign presentations. So I think that's one of the things that could benefit from what you're asking for, right? General, generic crypto operations based on unsecure hardware in the browser.

Yeah, I think it would benefit enormously. I mean, so many things would, you know, I think the whole, in some sense, you could boil down all of Web3 to, hey, we should probably sign everything that we do. That would be a more secure way of operating. That's just not really feasible today. There's no way to cryptographically sign API calls even. HTTP request signing is an option, but how do you do that? Where's the private key generated, stored, and used? You put it in the browser, it's not very secure. It's going to be deleted. So it's not usable all the time. You want it to be in the hardware of the device. It should be. That's where it's most secure, but there's just no way to leverage that right now. So I think it would benefit enormously. It's kind of baffling in a way that mobile apps have had this for many years now and web apps still don't. But if we can close that gap, I think it would be very beneficial.

But we— I just remember I was thinking about one other thing in the past, but we do already store a lot of, say, secrets in the browser, namely the— this pass— all the password managers store what they call the access tokens or passwords for us, right? And they are more or less secure. I mean, has anyone thought— because what we are discussing about now is basically, okay, you have a website that requires some information or some cryptographic operation on an object, let it be Verifiable Presentation Credential or something else, and then you transfer that information either to your device and perform the cryptographic operations there. Or would it be possible, since we have the cryptography APIs, right, in the browser already, that those communicate with a plugin? And of course the level of security is not the same. I mean, having something in browser add-on is not as secure as having keys in your HSM or mobile. But yeah, I think it's an intermediate step. I don't know, what do you think?

Yeah, well, password managers have different security models in general. I mean, they're password-based, you know. The password manager ultimately is one password at the end, and that is a shared secret. That is a very good security model in some ways, and it's very bad in other ways. I think the main reason is that— You know, we're all, I think, probably very aware of many password-based attacks, whether it's phishing, password compromise, you name it. There's all kinds of things. The goal of this is to avoid having to use passwords. That's— WebAuthn was essentially built to eliminate passwords. That was the goal. And the reason you can do that with WebAuthn, or at least try to do it, is that you can put a private key into your hardware device, and that has this unique quality of hardware generates the key and never exposes it, not to the app, not to the user, not the phone manufacturer even. It's not extractable. So that's a very unique security property of that hardware that WebAuthn is trying to tap into. I think password managers could also tap into it, but they typically, if they do so at all, it would be through a dedicated mobile app. That's really the only way to right now. Um, so I think it's, it's just kind of a different security model altogether. There are ways of relatively securely storing things in the browser. There are two main places, local storage and IndexedDB. Local storage is not super secure. IndexedDB is quite secure, but there are two problems. It's definitely not as secure as the hardware because it's vulnerable to malware and physical takeover attacks. So it's, it's Certainly not as strong as the hardware. Uh, the big issue is that the browsers delete it randomly or at scheduled times that aren't very long. So I told you about the worst offender, Safari, deleting it after a week of inactivity. Anything you put in the browser, it's deleted after a week. This is a recent policy, only a year or two ago they implemented this. This is for privacy reasons, they don't want super cookies. The problem is it just it completely negates the web app's ability to function based on that data because it'll be erased. And even in other browsers like Chrome, it could be erased at any time because essentially when browser fills up enough, the policy is just start throwing stuff out and web app has no control over prioritizing certain data over others. And so it's just not built in a way that allows the developer to, um, use that kind of storage. In addition to the fact that it's not as secure.

Yeah, I mean, I agree with— I mean, I really— so I agree with you, and it's clear. However, I'm still wondering, is it easier to create a secure, let's say, communication or channel between a mobile app and a browser add-on than an arbitrary web app and mobile.

Well, the problem with browser add-ons is they're not even available on mobile. You know, there's no such thing as a Chrome extension on mobile. At least as far as—

when you don't have the cross-device flow, it's not— I mean, how should I put it? You, you can secure quite well the interaction between the— when, when you have the browser on the mobile and the application, I mean, when you're on the same device, right? That flows quite secure. However, when you have a desktop or laptop and a mobile or tablet or whatever, so when you have two different devices, it's another story. So question is how to handle that case, because handling the first case when you have the browser on the mobile and application on the mobile, it's not an issue.

Yeah, well, I mean, so what I'm talking about here is applications that are web-based. They're in— they're running in the browser. So I think we're on the same page there. But the mobile to— or sorry, the desktop to mobile is not as bad as you might think. WebAuthn, for example, and I would imagine any future hardware-backed general cryptography solution, is governed under the same origin policy like everything else in the web. So you can't just randomly try to access someone's private keys. So there is some base level protection there. But also, if you are trusting the web app at all, you're trusting it to display whatever communication channel you would need to connect those two. So whether that's a QR code that you scan or something else, that is the communication that you're relying on. So I don't think— maybe if you have more specific things, I'll have to think more in detail, but I don't think it's The problem is mostly a user experience problem. It's not really a security one as far as I'm aware.

Okay, I shared the link to a discussion in the OpenID Connect working group. The cross-device flow has been discussed. Okay. I think it's a very nice conclusion that at least the SIP cross-device flow can be used only for attribute presentation but not to authenticate an agent or another device, right? So to check that, I mean, yeah, there's a big difference between like a cross-device flow and if you have an app and AGSM on the same device. It is, I mean, you're correct, It is— so the toughest question is the user experience, but having two different devices is really subject to many different attacks. So, I mean, but yeah, we can discuss this further.

Yeah, I mean, I think the way we've addressed this sort of issue is just everything is bidirectionally authenticated. And so we have a notion of requests and presentations in response to that. Everything is two-way. The request is specific to the device and the presentation is specific to who is making the request. I think those sorts of things resolve most of the problems you would be concerned about. I'll continue to think if there are some I'm missing, but I don't think— I think your point is very good, that it's, it's not a trivial problem at all, and it's definitely less obvious how you do it than if it's on the same device. But I think there are ways of doing it that are quite robust. The biggest issue is just how do you make sure, not just from a user experience perspective of not confusing the user, but also just in terms of not making a mistake in the user experience that exposes security problems. For example, if you're going to route everyone through the phone, that's how you're going to achieve high security, then you have to consistently do that and the policy has to be enforced very strictly. You can't accidentally not do that sometimes because you introduce other problems.

Just a very quick question. We don't have all that much time left, but You made the totally valid point, which I really appreciate, as seeing part of this about the activism and the community organizing around these kinds of changes in how people interact with digital identities. It's not just a technical challenge. And I also found your slide with the Google image search super effective at demonstrating that it's also, very difficult to sell to an end user this shift in how they interact with these services, these apps, these platforms, that they might not necessarily understand the distinction of what they're doing and why. And then we kind of have a chicken and egg scenario of unless there's a groundswell of interest or an awareness that people need these kinds of, layers of security, there's not going to be customer demand for it. So how do you kind of— any change is going to introduce friction to the process. That's just kind of a— are there any interesting ideas or approaches for selling that to a user?

Yeah, no, I think it's a fascinating problem, really. I mean, in some ways, people do change their behavior more than we give them credit for. Give ourselves credit for too, in the sense that there are words that are commonplace today that I think if you ask people 20 years ago, they'd think people are never going to use that. People are never going to understand what that is, whereas now it's commonplace. So part of it is there is real change. But I think most of the time it's abstraction. I don't know how my car works at all. But I do know that if I press the gas pedal and the brake pedal and turn the steering wheel, it works. That's all I need to know. And that's a beautiful abstraction that allows me to use the super complicated machine knowing essentially nothing about it. I think that is my mental model for public key crypto. That's what I'm trying to achieve is how do we build an abstraction that is like that, where the user doesn't have to know almost anything about it to use it effectively and to benefit from it. I think there is a groundswell of activity on a small scale in a little bit in developer communities. Certainly with Web3 stuff, there's a lot of focus on that, but also with bigger companies saying, hey, we really got to get rid of passwords. And that's kind of where WebAuthn came from. Okay, we got to build something better than this. That's not users saying it, it's companies saying it because the companies are liable and they don't want to deal with this anymore. And I think the user experience is actually going to be better in the end. It might just take a while to get there. But I do think a lot of it comes down to how do you communicate with these subtle security aspects, even to a developer community. We've found with our own company that talking to developers at other companies, they're just often not even aware of some of the issues and opportunities with cryptography. As one example, with a mobile app, you can do things like HTTP request signing. You can cryptographically sign every single API request, which is great. Security feature, and that's available. There are open, open source ways of doing that. We talked to a company that was a mobile app only company, and they weren't even thinking about doing that. One of the, of our team members sent me something about how Facebook didn't even implement HTTPS, didn't enforce it until like 2014 or something. It was incredibly late. So part of it is just a lack of awareness of what these security options are and what the benefits of using this sort of thing might be. So this is maybe a long-winded answer, but there's one other example. The qualities of a secure hardware element in a mobile phone are very subtle. This idea that you can ask it to create a key pair and then ask it to like sign stuff for you and never expose the private key to you is a very counterintuitive concept, and yet it's at the core of a lot of the security aspects of what mobile apps can do today. So I think What I'm trying to do is talk to people like you, figure out like together, how do we better explain this sort of thing to communicate to at least technical people at first, what the benefits are and why we should be using this kind of stuff. And hopefully that'll create a small groundswell that'll ultimately lead to user-facing change.

Yeah, no, I think it is slowly changing and stuff like FIDO is also interesting. And you also pointed out the paradigm of you use your key to unlock your car and to start your car and to open your house. And people are using their phones to unlock their front doors with a smart lock. But at the same time, they can't necessarily use their phone to unlock their bank's website on a different device. Or, you know, it's just not— there isn't that kind of infrastructure. And people are— I think also the, um, the pandemic has pushed a lot of awareness along in terms of people using it for vaccination records, test records. Um, people are used to using it for semi-official— it's not necessarily identification in the sense of it's not an ID, a passport, But it is important documentation that has a practical use in the real world that they need to display.

Absolutely. Yeah, I couldn't agree more. And I think the unlocking your house and your car is— like, I laugh at myself because I think of it as a burden to have some key I would plug into my computer to unlock. But why? I mean, I use that for everything. All I would have to do is plug it in and sit down and work for a while. I mean, it's not hard. But it's, you know, that's the path dependence that we're dealing with. But I think you're right. The pandemic is changing that. That's a new kind of path. Hopefully enough that it can move the needle. I mean, the reason I'm presenting this today is I kind of did what I could. I tried to find a way to use what exists today to do what I want. It can't, it doesn't really work the way I want it to. And then I tried posting in these issue threads on these specs, like, hey, you know, we should do this. And they, you know, mostly people didn't want to do it, and for understandable reasons. Like, I totally get it, you know, WebAuthn says authentication, so I get why I don't want to do more than that. So the reason I'm saying it today is I think I've kind of exhausted all the other options. Clearly community action is what's needed here, you know, that's what's going to actually change.

Exactly. But like stuff like WebAuthn also, it functions as proof of concept, right, from a technical level, that you can expand that. Yeah, thank you very much for a really super interesting and useful presentation. I have to drop out, um, and I will hopefully see you around.

Thanks everyone, great to talk to you. Take care.

Thanks, Liam. Just, just one comment. Could you post us the, the links that you, that you were using to the maybe the WebAuthn specification, the Web2 specification, and some of these threads where you commented on? Then we can include that in the in the minutes and also ask people in Slack, maybe point them towards that because I'm sure that other people feel the same way, that there is a missing piece here and maybe we can help create some of this community action. Another thing that we could potentially do is write a blog post in the name of this working group, right? You're a member of the working group, so if there are others who support this, Then that's— so there are a number of things that we could potentially do, but for now, if you maybe share some of the links so we can include them in the notes, that would be great.

Great. Yeah, no, I'm excited. Thank you. I'll email those to you now. And if you could just email me the recording when you have it, that'd be awesome too.

Yeah, fantastic. And yeah, thanks again. This was really great.

Yeah, no, thanks for having me.

All right, I'll talk to you later.

Take care.