Privacy Enhancing Mobile Credentials

So it's always hard to follow Justin, especially with the dancing, the dancing girls. But what I will say is what I'll talk about is what he was talking about was something that was deeply technical and coming to the end. And what I want to tell you about is something exciting, not as deeply technical, but just starting. So you have a chance to participate in setting the requirements. How many people in the room know about the Cantera initiative? Okay. About half briefly, it's an international SDO standards development organization, and a number of things.

One of its things that you may know is it does provides identity assurance validation in a number of, of contexts, but it also does deploy. It also does development of international standards in community groups. And I had one of those, one of those work groups and the work group that I had is called the privacy enhancing mobile credentials work group, P E M C. And the point of the work group is to look, to create a set of requirements and conformance criteria to protect the privacy of individuals holding or using mobile credentials. What does that mean when it's at home?

So a lot of us, especially at this conference are deeply involved in making sure that credential presentation, credential, reading wallets, all of that happens in a deeply confidential and assure manner, but that isn't the entirety of the story around meeting Alice. If we're gonna use Alice as the metaphor, Alice's reasonable expectations of privacy, the ISO 18 0 13 dash five, which is the in person standard for mobile driving licenses is specifically for, in person presentation. They're working on dash seven, which is the online.

We, we have the verified credentials, which is, which is a data model, leaves questions about transmission, but all of these things are very good to moderately good, depending on who you talk to on, on security and confidentiality. But if you, if you use the human analogy, what these assurances do is if I I'm at I'm at a party or I'm at a social event and I lean over and I whisper something that I think is private in my friend's ear, that's a secure communications channel. And there's a whole bunch of social conventions around the level of trust that I have with my friends.

So I've just met Nick this week. I've lean over to him in the crowd.

And I say, Nick, I'm, whatever the secret is, that's a secure communication. We've done. We've met all the requirements, but now I'm trusting Nick that he's not gonna share that information about with, with other people in the social context of what I shared that information.

That's, Alice's reasonable expectations of privacy. They, they changed in context, the nature of the information, all kinds of things. And we don't have those levels of assurances. And because, and I don't have to go over the history of the last 15 years about how trust and institutions has been eroded, whether they're banked, they're government, financial, social networks, whatever, how do I, how can we pro provide that level of trust? That's what we're trying to address. If you are using or building mobile credentials, how do you provide that level of trust?

So the prior work, there was a discussion group that produced a report it's available Cantera initiative.org, go to the reports and recommendations. You can read this, but on the left, you see the, the ISO MDL, the standard three part set of interfaces between the issuing authority, a motor vehicle or ministry of transport, that issues a driver's license, the MDL holder, the person with the driving license and the MDL verifier, which is I've heard varying statistics, but one in five, one in 21 in a hundred times, you're actually using it as a credential for driving.

You're much more often to use it, to prove that you're of, of age to, to buy alcohol or cannabis. I'm a Canadian.

So we, we do both and that. So that's the that's, that's one of the, the typical use cases. But on the, the right hand side, people in this audience will know this one, the you've got an identity provider, an IDP, an individual, and a relying party, or an RP and off to the right DLT if you're using SSI and kind of blockchain, but what's the, what are we focused on in, in this work group?

So one, two and three are the interfaces set out in the 18 0 13 dash five spec and a, B and C on this diagram. I won't use the laser cuz nobody online can see it is the similar, the similar pattern. And what's important to remember from I'm a privacy guy is the MDL holder and the individual are more, are gonna be the same person I don't know about you. But when I pull out my phone, I have a little folder of wallets. I currently have eight wallets in there, which you know, that's crazy.

But if, how do we guarantee a privacy for the data flows or the metadata that flows between these C is where the flash passes live. And we don't like flash passes. So please read, read that report, but that's just a report on, on the situation. And in 18 0 13 5, the, the privacy elements are non-normative, that's that standard speak for, you should do this, but you don't have to. So these are the, from a technical perspective, this, this triangle is typically what everybody sees, right?

You got the, the, the holder system, the verifier system, the issuer system, the issuer, the, the relying party, the, but behind that, there's the individual credential holder, the person using software that, or the verifying entity using software hardware. So there's actually about five actors in the system.

And, and to, to do privacy, you have to account for all of those actors, not just the technical actors that rely on a lot of the good work that people in this room are doing. How do you do that? The acronym that sometimes I see at this conference, IGA identity governance and assurance. This is in that same space, right? Alice needs to trust your institution, not just your transactions, right? So what is that for issuers holders and Anders? So I've limited time.

So I just wanted to, to, to look to cuz this is an open invitation for everybody in this space to come a, join the work group, but just take a look at the work group. Canera does things in a fairly transparent manner.

You can go to the confluence page, the Wiki Canera, and you can keep see the current state of the work and what we've, what we have, what we're pivoting to we're we're producing a report just in an early report to, to share with people in the, in the community of, if you want to think that you're going to be able to get a trust mark for privacy enhanced credentials, this is what we're thinking about now. And this is the direction that we're skating, right?

So you, you can, we can sort of get people flying in the same direction. And what we've done is we've provided three sample requirements that we think may survive the, the process. So there's three categories, information for issuers. So that's what you can read as well as I can. And this is what a sample requirement looks like, the way we've currently formulated it. And you'll, you'll, you'll see these things. The issuer must ensure the existence of functionality allowing selective data release, right?

So just because I'm acute 19 year old girl presenting my, I know that's a hard stretch presenting my ID to doorman at a, at a club, right, right now in the physical world. If the doorman is so inclined and has the sort of visual acuity he could harvest the address information and a stocking situation can arise in a properly deployed mobile credential, all the doorman would see on his, on his hardware is, is a picture says, this is the person that's actually presenting. And a green check mark. She's old enough to drink letter in and no retention beyond that. That's transactional.

That's built into the MDL, but there's no assurance that John's bar and grill is actually going to fulfill that pro and, and, and do that. So that's where this trust mark comes in. And so this requirement applies it's in part B, we call for issuers and it applies to the privacy principle of consent and choice, which is available in NXE in a number of other ones, similarly information for providers. So if you provide a wallet or you provide an SDK, if you provide that kind of thing, what does the sample requirement look, look for there, transparency to hold her at mobile credential presentment.

And this speaks to the principle of openness and transparency will expand all those acronyms later for people that whose favorite acronym is AFA another F acronym, but that's a separate issue. And then finally, cause I want to leave some time for questions.

If there are any or, or I'll go back and go into more detail information for verifiers, if you're a live party, if you are the doorman, if, or if you're the, or if you're the company that provides the doorman with the hardware and the software to do the verified, what are your requirements, guidance for entities that provide applications or software guidance related to the operation of the device or guidance related to the maintenance of the verifier systems.

And what's this, this requirement would apply to verifiers issuers and providers has to do with information security and what it states all identifying data shall be transacted through encrypted channels. So this is built into a lot of the stuff that we do, but we wanna make sure we touch base that those bases are covered. So that's the whispering in the ear.

That's a, that's an encrypted channel, only Alice and Bob get to access the identifying data in the transaction. So that, so I raced through that, cuz I, the 20 minutes panicked me, I didn't want, so it really is.

I, I want people in this community join the, join the work group. Even if you can't make the, the meetings, which are three out of the four weeks of, of the month signups that you can. So you get on the main list. So you can start to see the requirements, cuz we want to have a full library of requirements. Cuz if your, if your company, your organization or your user base or your community wants to say, yes, we're using verified credentials.

Yes, we're using mobile driving licenses for, for identity verification, onboarding or proofing, but you can also trust us to protect your privacy. After the transaction is complete or have a trust mark that will be useful and presentable to the regulatory, the privacy or data protection authority in your jurisdiction, please join us and help define these requirements. I think that's, that's it. Unless anybody wants me to go back and look at one of the requirements in more detail, given how much I raced through that.