 OK, so hi, everyone. Again, my name is Ola Ben-Harr. I lead the developer relations team at Google for payments in Google Wallet. But I also have a broader role where I represent Google, including Google Wallet, but also Android and Chrome on the Open Wallet Foundation, which Google recently joined. Google has a long-standing history of supporting open ecosystems. I truly believe that I think especially for a topic like wallets in general, digital identities, it's very important that we work together as an industry, together with governments and nonprofit organizations to build solutions that are truly secure, comprehensive into our parable, to make it meaningful for everyone. Because I think this is something that's going to impact us all. And first of all, we're also consumers. And I think we're all playing a role in how this ecosystem is going to look like in a couple of years from now. So today, I'm very happy to announce a code contribution. So we decided to contribute the Identity Credential Library, which is used by many commercial wallets, including Google Wallet. It is actually a set of libraries and wallets in sample apps for a wallet and a mobile verifier for real-world identity. We have the maintainer, actually. David Zutin couldn't be here with us, but he recorded a video to talk more about the library, to give you an idea of what it is and what you can do if you're working on digital wallets or digital identities. So Thorsen, I think you have the video and we can play it now. And then I'll say a few words at the end. So first of all, thanks a lot for your contribution. Absolutely. And I had the pleasure to talk to David last week and he's really passionate about what he does. And yeah, then let's watch the presentation. Hi, I'm David Sofen. I work for Google in the Android Platform Security team on hardware back security. The past five years have been working on real-world identity, specifically MDoc MDL in the ISO SE 17 Working Group 10 Working Group, where we published ISO 1813.5 for MDL and mobile driving licenses. So that end at Google, I worked on creating a library and integrating MDLs and MDoc into Android. And I'm going to do a presentation about that. We'll just bring up the window. So here it is, status and roadmap. So first of all, everything in this presentation is just current ideas and thinking. There's a lot that already is released. There are also some things we haven't. So don't depend on anything until it's released. So what is it? The Identical Library is a library, a set of libraries, actually, and example apps for real-world identity. The initial focus was MDL and MDoc, according to ISO 1813.5, and also related standards like 1813.7, the 2322 series, and even things that are MDocs, like verifiable credentials. It's been hosted at GitHub for a while, I think, 2019 or 2020. And it's available under the Apache 2 license, like most other Android code. It's all written in mostly Java with slowly converting sensor codlin. The library implements on-device provisioning, storage, perception, verification of MDL and MDocs. And an emphasis that implements the on-device parts, things like provisioning, as we'll see in the next slide, involves the issuer, obviously. So we don't do anything for the network protocol or user-proofing. It's not really standardized yet. There's some early steps. But for now, our library just does whatever you need to interface with the device. The library uses hardware-backed key-store and remote attestation, which is important because it gives you strong guarantees that the private key material never leaves the device, which is important for anti-cloning. So you can't just steal someone's MDL. You would need the key, which is an hardware-backed key-store. The library itself is quite production quality. I've been to all but one of the MDL test students, organized by the working group, Ternisal Group. It's used in several production wallets, many of them certified by UL, and Google and Google Wallet, which is created by a team, not my team, but I work closely with them. The library has strong focus on testability. So there's a bunch of unit tests and also manual tests for Vincent Andixi to unit test. It's actually not restricted to Android. It's separated into two libraries. We call them identity and identity Android. And it's also, later versions are not dependent on MDL. The MDL and MDoc are split out into separate. Separate things and the call can be reused for the credential formats. So let's first look at the overview of the ecosystem in where you will use it. It's called the three-party model, where you have a holder that carries a credential around. That's just by carrying a plastic car. You have the issuer of the credential. That could be the DMV, in my case, the Commonwealth of Massachusetts, registered motor vehicles. And there's a verifier that the holder wishes to present the credential to. That could be the TSA. It could be an alcohol store or a bank or someone. So the library implements the in-person presentation protocol, including all the Bluetooth QR code and NFC bits. It implements, it does not implement the issuance protocol. It only implements out of a device site you need to implement it. We don't implement server retrieval, which is an option in 1813.5. But it's not very good for privacy, so our library does not currently support it. The library itself is used inside the Wallet app. The Wallet app is part of the OS. The OS is part of the device. And to do things securely, you need to do things outside. There are OS, you need to use secure hardware. In our case, Android Keystone. So this is kind of the concept of where the library is used on the holder side. It's also used on the verifier side, in the m.reader app, to implement the other part of the transaction in the device retrieval protocol, which is part of 1813.5. It can also be used on the issuance side. We don't do that, we're not an issuer, obviously. But all the primitives in the library can be used there, because I mean, it's not Android specific. So let's dive into actually what the library is about. So at its core, it's essentially a credential store, where you can have one or more credentials. So you could have a mobile driving license, you could have a vaccination document, vehicle registration, and so on. A credential is basically namespace data, coding term docker, generate property back, if it's a set of claims. So the type, the data type for credential, it's pretty abstract. It's useful for MDOTs, it's also useful for other kind of credentials. We identify a credential by a key pair. We call it credential key, where the private part is on the device, the public key can be sent to a third party. Another party could be the issuer. And we use hardware backed at stations, so whenever you convey the key pair, the other part that examines that station has a high degree of certainty that the private part of the key is in a secure area and it cannot leave the device. So that gives them a baseline of trust that the credential or whatever you use the key for cannot be cloned, which is very important. A credential also has a number of authentication keys. In 1813 part five parlance, the code device key, these are the keys used to actually make the attestation at presentation time. So that's what you sign the data with. And the reason we support more than one is to implement the concept of not leaving any traces. So if you use the same key over and over again, the relying party could track your footsteps around. So essentially, we think of authentication keys as simple use. And the idea is when you get your credential from the issuer, you get 10 or 20 of them at a time and you refresh when they run out. Maybe they're time limited, maybe they only valid for 30 days. But talk about other problems like revocation. So that's the general architecture. And to do this, we defined a couple of abstractions for how can we store data? How can we do, how do we minus the secure area where the key material is implemented? And so we have some abstract interfaces and of course some concrete implementations of them. For the secure area, we have an implementation based on a member key store, which is an API that's been around for a long time in Android, probably a decade or so. That gives you hardware back key support with remote ad station. We have an implementation of storage, which uses encrypted, which stores the data at rest encrypted. And the sense of race nicely with Android so in order to use a key, you can require biometric authentication. The user puts in the system end code, such as to protect the key material, make sure only the device owner can actually present a credential. We also have implementations of these in software that's using the Bouncercast library. The whole point of doing this is just so we can run it outside Android. Mainly so we can run unit tests and also to prove that the abstractions work. So in addition to that, we have a big, a lot of mDoc support, and that's lit up into two bits. We have all the generic mDoc code, which basically handles all of the data. It can pass and generate the device request, CBO data structures document request. It can deal with the mobile security object or the MSL, can generate and pass those. The Android specific parts of it do mostly with presentation, the presentment phase. So we do QR and NFC engagement to start the transaction. And then data transport is then over BLE, Wi-Fi aware and NFC. And in addition to that, we also have helper classes to do the whole verification and presentation ping-pong. All of this implements the ISO standard 1813.5. And it's been through different test events. It's well-tested. There are no explicit Android dependencies. As mentioned, you can see all the Android specific bits. It's in its own library. So you can use all of this on the verification side. For example, if you accept mBLs at a website where you can use device response parser, then it will work. There are no explicit mDoc dependencies. You can use the credential, credential store abstraction for other credential formats. For example, SD-Geard is like, I like to call it the JSON version of mobile security object. It matched very well to that. The subtractions for the secure area, we like Android Keystone quite a bit. It's very versatile. It's very robust production quality. But if a wallet app wants to include and use its own secure area, for example, some kind of external device, maybe a cloud back thing, where the key is stored, or maybe they have a secure element with a java card applet that's certified, they can do that. They can just implement the secure interface, which is part of the app, and then all the rest of the code will use that. That's quite nice. Finally, one philosophy is that we don't just want to give people a library, and then your developer is like, oh, how do I actually do this? So batteries include it. We have production quality, both wallet and reader apps that use this, and we keep them up to date. I'll talk a little bit about those. So the wallet app, when you build it, and anyone can check out this code from GitHub, build it, and run it on your Android phone in five minutes. So it's ready to use. When you start the wallet app on a fresh install, it looks like this. So you add a new document, and in this case, we have different document types. So this is an MDL. We support three other doc types, which are also MDUX, vehicle registration, EU, PID, and vaccination document. So you select your document type, your card off, what name the document has, which secure area to use. In this case, it's Android KeyStore. Whether you want user authentication in order to present it. How many authentication keys you want? In this case, 10. How to do the MDUX authentication? There's both MDUX ECGSA and MDUX MAC authentication, which elect to curve cryptography, curves to use, and so forth. So it really supports a lot of different options. This is not because this is good UI, it's moment for developers and testing. So if you go to a test event, and the reader you're interacting with has problems with, say, ED25519 keys, you can create a credential with that and you can test and figure out what it is. So that's really the attempt that these applications showcase the whole library, and it's useful also for testing that the library works as intended. So once you create a credential, you can actually insert your own data, and in my case, put your own portrait image in, and this is what I did here. And then you're ready to go. There's your driving license you can see in this screenshot. There are actually two documents. So that's the holdout. Once you have a document, it says NFC-TAT with your MDUX reader, and you can just have it against an MDUX reader and it'll start the transaction. We'll have a video in a little bit but before that, let's talk about the verifier, the MDUX reader app we have. So it allows you to specify what documents you want to request. So we have MDL for US Transportation, which is the default one, which basically just asks the user for five or six data elements, the same you would need to show if you go through the TSA, for example. You can also request some of the other document types that I mentioned. Mobile vehicle registration, vaccination, EU, personal ID. And you can also request multiple documents. That's the request MDL plus my card and the test with linkage. That means that it requests a data element in both of them that should have the same value. In this case, it's the driving license number. So it's a pretty flexible application. If the MDL M documents acting with does not have NFC, you can scan the QR code. Like this, it's using the camera and you can see the wallet app in the camera area showing a QR code. And once you receive the data, it shows a response with a lot of green check marks. It's probably not the best UI, but again, the audience here is probably not end users. It's developers and people deploying real-world identity. There's a bug here. That's by showing a red cross that the document signing key is not recognized. That should be a green thing, but this is what it is. When you create demos, sometimes there are bugs, which we face. You can find issues at GitHub. So the next slide is showing what the MDL presentation looks like. So we'll just roll the video and I'll narrate. We have to be varied from the reader on the left and the older on the right. So the reader selects what you pressed. And now, the product is sent to a lot of sites to not send stamina in. Not send data. Now the user is able to find the result release, the device signing, send over through to the button to the given name. So that's pretty much it. If you see the MDL demonstration and MDL presentation in the past, maybe this wasn't very exciting, but this is what the apps do right now. And I think they do it well. So let's go to the next slide. Slide where it's just talking about what we're kind of to work on in the future with this library. So right now we're focusing on integrating it with an integrating the apps with all of the internet presentations. That is presentation of your credential not to another device, as you saw just before in the video in person. We want to present them to other applications on the same phone or to websites. To that end Apple actually proposed the mobile document request API I think last year back in 2022. And we've been working with them quite extensively and also other browser vendors to what is now the identity credential WICD which is web incubation group in W3C and so we're working with people stakeholders in the W3C to have a forum to work on this which is going to start up real soon now. I've been working with Android and Chrome teams to add native rich APIs which this browser based API can use and also so we can convey credentials to other Android apps hoping to share a lot more about that in ISO and other standardization groups in the near future. We will continue to be active in standards groups so I'm personally very active in ISO a lot of work is going to happen in W3C go to unsolvable events and so forth. Another thing we're working on is an open-source javacart to facilitate M.dot presentations when your phone is out of battery but the phone has enough battery to still power the NFC chip and there's already some phones for transit hotel payment that is to also do it for identity this is to inspire enough confidence in digital identity so people can use it even if the phone is out of battery which might be quite important that's an interesting privacy issues with that because you can't consent to a request because there's no screen the phone is almost out of battery so it will probably only work if you have read authentication some authentication of the gridline party hope to have some more information about that in the near future we're also working on supporting other credential formats than M.dot in the library itself and finally we want to add support for other kinds of secure areas than just Android Keystone and I think that was about it so thank you very much for coming to my talk I hope this was useful if you use the library just feel free to file issues on GitHub send me email and move forward to hearing from you thank you so for those of you that are interested to learn more about the library you can find it today at this link that Torsten just presented as I said we decided to contribute the code also to the open wallet foundation so soon it will be moving under the open wallet project also I think if you have any questions David is part of the technical advisory council of the open wallet foundation which is an open forum anyone can join so you're very welcome to join these meetings as well or as David mentioned just file issues on GitHub thanks everyone thank you very much and