Good afternoon. What I'd like to share with you today are challenges that we have seen in building out the mDL, Mobile Drivers License, ecosystem. I'm going to briefly cover our main goal and the main challenge that we are experiencing in that regard. I'm going to go over what we already have in place in building that out. And then what do we still need to do to get to where we want to be. What is our main goal? Worldwide reciprocal mDL acceptance. We want to be able to take an mDL that was issued in one part of the world and have it accepted anywhere else in the world.
So, really easy to say, I think in practice not so simple to implement. But that is our goal. Our main challenge in this regard is a result of our ecosystem. This is the generic ecosystem we have in the mDL world. You have your issuers, you have your mDL holders and you have your verifiers. And the challenge that we have is one of adoption. The chicken and egg problem. The holders are asking why do I need to get an mDL if there are very few places where I can use it. And the verifiers are asking why do I need to invest if there are no holders out there yet.
That is what we in the mDL world today see as our main challenge in building out the mDL ecosystem. So, in building out the ecosystem, what do we already have in place to support all of this?
Firstly, we have standards. So, we have the technical means to ensure an interoperable transaction between a compliant mDL and a compliant mDL reader. It doesn't matter where in the world. If both parties are compliant with the standards that we have, you have a technical path to a successful conclusion always. Regardless of the implementation choices that the mDL or the verifier may make within the confines of the standards that we have.
So, we have the technical means to achieve interoperability. Secondly, we do have wallets. We are provisioning mDLs into wallets. We have in North America wallets from the major platform providers. We have wallets from other contractors. We have wallets developed by issuers themselves.
So, there is no shortage of wallets into which we need to provision mDLs. Thirdly, we have issuers. We have a number of issuers already issuing mDLs in North America. We have issuers issuing mDLs elsewhere in the world. And we see more issuers starting to issue frequently.
So, there's a growth in the number of entities that are issuing mDLs. So, there's no shortage to that either.
And then, fourthly, we have trust lists. Within the mDL ecosystem, the mDL standards define a structure within which certificates of issuers can be packaged.
So, that relying parties can have one trust point instead of having to go to issuers individually. In North America, my organization, AMVA, has implemented an instance of that for North America. In ISO speak, or in mDL speak, we talk about a VyCal as the package.
So, we are a VyCal provider in North America. In Australia, Ostrodes, a sister company to AMVA, is standing up their packaging, their digital trust service that acts as a VyCal provider. And we've heard indications that in Europe, the same concept is being explored, this trust list.
So, there's a lot happening in that front. And once that is in place, that will provide the trust anchors for relying parties to trust mDLs from any part in the world.
So, that part of the infrastructure is happening. So, what's missing? What can we do to help move forward adoption to prevent this chicken and egg situation? We have found, surprisingly, that issuers, very often, do not consume the credentials that they issue.
So, our advice is, issuing authorities, you need to take your own medicine. You need to set up your own environment to accept the mDLs that you issue. You need to set your own environment to accept mDLs that other issuers may issue, so that when customers come in and say, I come from a different jurisdiction, here's my mDL, that you're able to consume that. You need to talk to your fellow agencies in your state or in your jurisdiction to also accept it.
Again, it's surprisingly uncommon for issuers to actually consume their own credentials. The next thing that we need to do is to work with relying parties. We need to inform relying parties about the mDL as a concept.
At AMVA, we have staff dedicated to just reach out to relying parties to inform them, because there's a lot of misunderstanding or just common lack of understanding of how this works and what it can mean for relying parties. The next thing around the relying parties is to identify what we call the champion relying parties. Relying parties that understand the value and are willing to invest, even though the return on investment is not going to be immediate. In general, when we talk to relying parties, they typically get the value, why we're doing this.
You're now able, when in the past I had a physical document and sometimes I wondered if this is good or not, and now I can, in the mDL world, say with certainty, yes, this information is good. What makes them hesitant is the fact that there aren't too many of them out there yet. They will not see the benefit of their investment as quickly as they would like to see. What we're doing is we're identifying preferably bigger relying parties that have this vision, and as I said, that are willing to invest, even though the return on investment is not going to be immediate. And there are those.
Again, in the US, we have the Transportation Security Administration, who has seen the value and they've invested in putting out the infrastructure, the reader infrastructure, at all the airports, even though the number of mDLs that have been issued when they made the decision was still very small. We also have corporate entities in the press. Amazon is a good example, most recently, that have said, yes, we believe in this concept and we're going to invest in this because we can see how this can benefit us as this grows.
The next thing we need to do is more like a collective thing for entities that prescribe what wallets need to do and entities that build wallets. It's the user experience. It has been discussed in this forum some this year. It was also mentioned last year. But we really see the whole experience as something that often is neglected. When I use my wallet, I take it out, I use my card, I put it back, I put my wallet back.
It's easy, it's simple, it's quick. When we now have digital credentials, we created many nice things. Selective data release, the ability to know exactly who the verifier is, the ability to know what the verifier is going to do with my data. All of that additional things now create additional decision points for the holder. Somehow those decisions need to be made. We need to be very careful not to have those decisions slow down the holder in the process of using your MDL. This is especially true in in-person use cases. If I'm standing in a queue, I have people behind me.
I don't have the time to read through a bunch of stuff. I want to say, yes, I want to share and be done with it. So the challenge is for the UX designers, for the wallet designers, to come up with something in that area that makes sense. Some of the challenges in the broader context of the user experience, though, is that we still want the holder to have ultimate control. There was a very interesting presentation yesterday by Hank Marshman that concluded, based on research, that the holder is not necessarily the best entity to make an ultimate decision.
Yet, we want the holder to have control. So we need to solve all of that in our wallet design regardless.
Lastly, we need to facilitate relying party trust across jurisdictional boundaries. Your local jurisdictional protection only goes so far. You may think that if I take my European driver's license and I go rent a vehicle outside of the European Union, I'm covered by GDPR. I'm not a legal expert. I have been told that if the rental company from which you hire does not advertise in Germany or in the European Union, no, you're not covered by GDPR.
We've also heard from DG Move, who's writing the fourth directive on driver licenses, that it may very well happen that European driver license holders will be allowed to share their MDL outside of Europe without the relying party having been registered in Europe. So your local jurisdictional protection, in terms of any privacy rules, only goes so far outside of your jurisdiction, and driver licenses are meant to travel. So we have this problem. The most promising solution we've seen so far for this conundrum is an initiative by the Cantera Group.
They have a group called the Privacy Enhancing Mobile Credentials Group, and they've defined requirements for a trust mark that says this entity is following privacy principles based on the ISO 29100 standard. So they've come up with a bunch of requirements. The beauty of this approach is that the set of requirements is not bound to a particular region. It's not bound to a government. It is an international set of requirements for entities that comply with privacy-preserving practices. And as I said, that's the best one we've seen so far.
We'd be very curious to learn from anyone that may have experience in other solutions to address this problem. And those are the major things that we have seen that people can do, entities, organizations can follow, to help increase adoption and build out of the MDL ecosystem.
Again, if there are any other thoughts out there, we'd be very happy to hear of them. We sincerely believe that MDL being used worldwide is going to be a benefit for multiple stakeholders. And that brings me to the end of my presentation. Thank you. And a great presentation it was, too. MDL has been mentioned several times this week already, and so every time I heard it mentioned, I thought, well, this is great, because I knew you were going to come along and you were going to set everything straight.
Thanks so much for setting out the concepts for us and proving that the audience is actually awake and listening. We do have some questions. The first one is, how would you prevent malicious verifiers, such as ones that overcollect data, from getting into the ecosystem? That's a very interesting question. Within the concept of MDL, we have a requirement in the MDL standard that any type of reader verification shall not be performed in respect of the mandatory data. We want the holder to be able to share their data whenever the holder decides to share the data.
So there is no notion of controlling who may and may not read your information. The holder is responsible, which is why when we looked at the presentation made by Mr.
Mushman, it really struck home that the focus should be on how do we get the relying parties to be responsible. Now, I know that's a notion that people may strongly disagree with. The challenge, though, is if you don't agree with that, someone else has to decide where the holder is allowed to use their stuff. And that's philosophically a very challenging thing.
Okay, great. So now the second question we have is, the MDL spec notifies the issuer whenever a credential is used, which impacts privacy. So can holders keep their MDL usage from being sent to the issuer?
Yes, they can. And that may be a misconception. The 18.0.13.5 MDL standard has two modes of operation. One is called device retrieval, where the issuer is never involved during transaction time. And the other one is called server retrieval, which indeed is the relying party retrieving the information from the issuing authority after the holder consented. Both models are there. Issuers have to choose which model they're going to follow. And it's not like flipping a switch, moving from one to the other. You have to intentionally set up your infrastructure for one or the other.
So if you decide that you want to follow the server retrieval, which has privacy implications, it's a conscious decision. And I want to add to that that we've had this discussion in the U.S. And we are going to come out with requirements for North America that prohibit the use of server retrieval. So in the U.S., server retrieval will be prohibited. And you have to, in order to get your key into our trust list, you shall not follow server retrieval. Right. Great question. Great answer. Please give it up for Lofi Yordan.
