The DNA of Digital ID – Enabling Roaming Wallets

You very much Afternoon everybody. So I'm Mother Shaw, chief identity strategist at the Open Identity Exchange. I'm going to the next 20 minutes or so just take you through some of the work we've been doing around trust frameworks around the globe and interoperability. So I'm gonna talk to about what we termed the DNA of digital id. I'll explain a bit a little bit about that, what that is. And then we talk about how that enables roaming wallets. So how can wallets roam from place to place? And all of this is in a context of fast evolving trust framework. So exactly how are they evolving?

What are we seeing and what are we looking to do to extend our guide to trust frameworks and how we help those who create trust frameworks to cope with and move forward with in that, within that evolution. So digital ID DNA, we've analyzed eight trust frameworks around the globe. And what this evolved was going through the policies as published by or as shared with us by these different frameworks. And these are very different frameworks. They are mature in some cases, SeaPass, Sweden, massive penetration in the markets that they are serving, others are evolving.

So the EU with E-I-D-A-S two, we looked at the, the, the prevailing version of E-I-D-A-S two at the time. This was done last summer. The UK framework that's, that's been evolving as well. That's in beta at the moment.

nist, when we did the analysis, we looked at version four. Now you can argue NIST isn't a framework, it's a set of standards. But in its evolution in version four, it's starting to touch on more and more elements of some of the things the other framework's taught touch upon. And then moip more of a solution than a framework in itself. But it enables those who are creating digital ID solutions around the globe to take the base technical platform to build upon.

So we, we, we took from them a more technical view of the world. So these were deliberately selected as a variety of very different trust frameworks because we wanted to give ourselves a challenge.

We, we only did eight because as we started on the process, we realized this was quite a big job. So we, we drew the line at eight, but we will be doing more. I'll come on to that towards the end. And what did we find our finding? We coined the term was the DNA of digital identity. And that came about when we took the analysis and we zoomed out on it. And this is the analysis or part of the analysis in full. And it looked to me like one of those, when you see on, on television and on a crime drama and the looking at DNA readouts, it looked like one of those. And that's where it came from.

But we thought it was a good analogy because what it told us is that these are the same species, these trust frameworks, but they are different. They have their own distinctive traits, their own distinctive values that make them unique. And that's maybe not a surprise because over the years they've learn from each other, they've evolved from each other. Built upon thinking of from ourselves and others as the, as time has gone. Some of these have been around nearly 20 years that we looked at.

And we've, we, we divided this into two areas. The general policy rules that you know, that cover things like data management, the different roles in the ecosystem, how it's governed, security, technical complaints and disputes, and then specifically the identity assurance policy. 'cause those general rules would appear in any kind of trust framework, trust ecosystem, they're not specific to digital identity.

They're, they're specific to good practice in trust. The bit that makes a digital identity ecosystem is what it does about identity assurance. So we carved that out into a separate part of the analysis. I'll drill into a little bit now about what we found on each of those. So in the general policy areas, we ended up dividing these into 15 different areas and underneath those there are in total 79 different policy characteristics. So there are 79 different things in terms of policy that these frameworks address. And that's not that many.

We thought it would probably be more when we started out, but we ended it with 79 different characteristics. And those characteristics have between one and eight values. If they have one value, it means all frameworks are the same because all of them are exhibiting the same value for the same characteristic. If we have eight values for a particular characteristic, it means they're all different. And generally we've got a mixture of somewhere in between, which means they are, you know, they, they are similar. But we now understand the similarities and the differences.

And as we did our analysis, the bottom blue line there is the number of characteristics we identified as we went and far from going for the first frameworks of the second, it didn't grow that much. That might have been because the second we did was the EU and that's very comprehensive. So when we did the other ones, there were blanks compared to what the EU was doing. But the values continue to grow and we expect the values will continue to grow as we analyze more frameworks. And the other area we looked at was the identity assurance policy model.

And what we found in here was that they all take the same approach. They talk about accepted, I've used the term credentials here, but we might be better in this case talking about evidence, evidence about who the individual is. And they take that and they validate that the evidence is genuine and they use, we've got eight broad headings of techniques that they use, including things like scanning documents, checking against data sources, cryptographically reading chips, putting them under IR UV sources to make sure that they've got the genuine elements.

An interesting one is it came from a directly from an authoritative source and I can verify their signature in five, 10 years time. That's probably the only validation we're ever going to do because we're moving to a world where the authoritative sources will issue the credentials digitally. But at the moment we're in this hinterland where we've got physical things that we're trying to digitize that we bring them into the process, then we, they we, they apply verification methods. So we know this is a genuine piece of evidence, but is this the user who is claiming to own the evidence?

Is the picture on the passport, the picture of the person who's now claiming to have this identity and to go through this proofing process? So we take a selfie, we cross match it to the picture from the chip is one of the validation verification techniques we've got. The secret source we found in here was how they combine these. So you might say, well I crypto read a passport but I also need to check against an authoritative source to see whether it's been revoked or stolen.

Put those things together, we've got more trust in the document because we now know that it's likely to be held by the genuine individual because it hasn't been revoked or stolen. So validate, verify, combine, and then combine again. So we then take these outputs of the validation verification process and put them in different combinations and outta that pops levels of assurance. And we did this across five outta the eight frameworks that we had because only five of them had published policies. And it worked. It worked for all of them.

And then we want to continue to do this with further analysis. So this analysis has, has been published now, but we haven't stopped our work. We're continuing to refine where we're going with this. And one of the things that we think we're going to create outta this is something called, when we published it, there was the open criteria exchange tool. It's a way to describe these policy characteristics systemically so that the rules of frameworks can be published and read and understood by wallets. The policies that are applied to credentials by issuers can be attached to credentials.

So they can be read and understood by others. And relying parties can express what they require in terms of policy to wallets. And often that will be, I require the policy of the trust framework that I'm dwelling in.

So, but what this has in the middle here is this wallet being barred by policy information and having to reason around that information and make decisions on which credentials are applicable and acceptable or are needed to be collected for certain circumstances. So we did a lot of work, you hear a lot of presentations talking about protocols around this and exchange of information and security. We're looking at the level above that and the policy that needs to be exchanged to make all of this work from a framework perspective.

And one of the things we identified as part of the analysis was that there are five, we call them golden credentials. And these fit into that assurance model I talked about earlier where there's a national ID card that is used to create a digital id. It's digitized or delivered in a digital format where it isn't. We're seeing the, the consistent use of passports, bank accounts, driving licenses or telco accounts are the four things that people generally, generally use. IT identity assurance frameworks.

And if these can be standardized and put in wallets, we could formulate a level of assurance wherever we go. And that will enable roaming wallets. I'll come onto that in a moment. If you want to get this paper, it's in the OX library. We will shortly be publishing the full details of the analysis. So at this point we've published a paper, we'll be sharing the details of the analysis probably by the end of summer on a website. And we will be analyzing further framework. So I've just been talking to some of the, the Japanese delegates who are here.

We're going to do an analysis on the Japanese proofing standards and policies, which collectively would form the equivalent of a framework. We want to look at Brazil, we want to look at Australia and New Zealand. We want to extend this to the, the whole of the G 20. We've done six outta the G seven already. We want to extend this to the G 20 where there are frameworks and policies in place.

So this, this is an ongoing piece of work we're looking at and what this leads to is enabling roaming wallets. So when I have a wallet that's trusted and functional, I don't have one at the moment. All I've got is an Apple wallet on my Apple phone in the world we're all talking about here where we're getting trusted wallets like uni wallets or private sector wallets that I have trust when I have one of those, I want it to work wherever I go and I may have more than one wallet, but I want them all to work wherever I go Where the credentials are able to roam.

So some of my credentials won't work, but my core credentials, some of those golden credentials I've talked about passports, driving licenses, bank accounts that are minted to international standards and are from trusted issuers should still work. And then I can present those to relying parties or I can use them to formulate a level of assurance in the local context. So I say not all of my credentials will work. So some of them will gray out and that will be things like my loyalty cards.

You know, my, my Cove loyalty card I use at home, not relevant over here because the co-operative system's different. My BrewDog loyalty card will work over here because there's a BrewDog just down the road. The pubs are bumping everywhere now. They're all over the place. I'm a shareholder so that's good.

But that, so we are really exploring this concept of a, of a roaming wallet and how do we make that happen? And there's two ways we see this happening using the the, the O set as we described it. The policy criteria that we found can be used in two ways. One is in static decision making, policy makers sitting down, looking at another framework, deciding where they match and where they don't, and making a decision on the credentials and wallets they accept from elsewhere. And then putting those on trust lists.

So that's one way to achieve interoperability and that's a static method of assessment. The other method is a more dynamic method where the wallet lands in a country, a relying party makes a request of it and it works out where it is. The framework is existing in, it reads the criteria for that framework and works out what credentials it's got within it that can meet that criteria. And we think that's a much more scalable model because it doesn't involve lots of static assessment, lots of bilaterals between different countries in terms of how interoperability works.

So we think this is the way things will go in the future and it's probably going to be a bit of a hybrid at least for a while. But we continue to, to analyze this and look in more detail. So I'm not, don't worry, I'm not gonna take you through all of this, but this is an example of what we're looking at at the moment. So this is around some of the static policy rule trust at the top we've got the static assessment. Some policy makers sit and make a to static decision around what's accepted and they write those things to trust lists.

And then when the wallet roams, those trust lists are read as to what wallets are accepted, what criteria are accepted. And then there's a reasoning process around filtering down the wallets, filtering down the credentials in the wallets to meet the relying party's criteria. And you'll see there's a key role on here, which is this credential selector or wallet selector as we've just evolved it to in the latest diagram. It works out which wallet or wallets contain the credentials that meet the policy criteria that the relying party is asking for.

And that has led us to an, an another key role in the ecosystem. But from the end user point of view, one of the things I was going to do at these conferences was give you a demo of how all this would work. And we were gonna write a Figma tool, you know, do this and show a, you know, from a user I land here and you know, it's a, we thought it was a highly interactive user process actually it turns out it's just this screen where it's something tells me you're being asked for these credentials, you've got these wallets, which ones do you want to share?

And then that the actual sharing goes back to the wallet. It has to 'cause the, the credential is in the wallet. So you'd bounce into the wallet, agree to share the information, then it gets fed back to the reliant party. So that's the ecosystem that it looks like we're creating at the moment with this new role with a wallet selector playing a role in helping the user through that process.

And I, I touched on the assurance policy model. So there's this static dynamic decisioning thing flows into here in a slightly different way. Are we going to agree that LOA substantial in the, in Europe is equivalent to IAL two in the US on a bilateral that might be agreed again on a multilateral basis around the world? It doesn't feel like that's possible. So this is where we feel that if we've got these golden credentials, two standards in wallets, they can be read And interpreted locally to come up with a local framework.

And we're doing some kinda desk based work to, to region through that. But the assurance policy model we've got shows us this should be the case. If we've got trusted credentials, we can formulate a destination level of assurance wherever we go. So my wallet ends up with an IL two in it with a substantial, with a UK medium that has been formulated for particular use cases wherever I go. And this leads us to how trust frameworks are evolving.

So today, this is the model around digital identity trust frameworks. In the middle we've got an identity provider. They tend to do two things. They're the two elements of of our analysis. They do proofing and then they give the user something to manage the proof. It's an account, it's, it could be a wallet, but the, the, the digital identity providers are generally doing those two functions. And around that we've got sets of identity assurance rules and general digital ID account rules.

The two sets of rules that we've already identified as we move to the world of wallets, we're adding more roles. We've got the issuer, which you will all be familiar with. We've added another role, the use case process provider, which is where this wallet or credential selector thing sits. It helps the user on behalf of the relying party step their way through complex use cases and work out which credentials from where to share. It doesn't do the sharing itself, it's, it's a helper role that, and it's the, that's the first time I've used the word helper using the word agent previously.

That helps Put the smart into this. We used to be talking about smart wallets last year. We've now moved to this model where actually the combination of some of these roles would be smart, but we have discrete roles potentially because there may be many wallets. Therefore this helper role, the use case process provider is going to be required. And we're doing a lot more work on that in the working group at the moment. So our next steps on all of this are the analysis we've got. We're going to turn that into a trust framework comparison tool and publish that.

We're looking at the governance required for interoperability of credentials across frameworks. We're expanding our trust framework analysis to include the rules for issuers, credential providers and for those use case service providers. And we did some really good work in the city summit on Monday around that and what those rules might be. And all of that is done in kind of conjunction with the city hub group.

And then internally at the moment we're delving into this all those nasty sequence diagrams of how is this gonna work in practice static and dynamic versions, additional roles around the wallet selector. So how can we, you know, see this working in the future and what are the policy rules and layers we need to put on top of the tech to make all of that work reminder the QR code of the paper is there if you would, to see it. And that's, that's me I think of the time. I'd say. Thank you Nick, does anybody have a question they would like to put before?

Yeah, please introduce yourself. Yeah, my name is from identity clarification party in ferret. Actually I have two questions if you allow me. One's a small one. Can you elaborate a little bit on that concept of trust list? What kind of beats are in there? And then the second question, if you put it like this, aren't you basically creating a meta trusts framework? 'cause it's trust framework to Yeah, trust. Trust frameworks. Yeah.

So on the first one, the trust lists would be lists of wallets and credentials from wallets that are trusted by the policymakers, which is kind of what the, you use doing. You know, you're putting a wallet on a trust list and saying it's part of the ecosystem. We're extending that, I guess to say credentials in particular wallets are trusted and there's a policy layer that adds on top of that.

Is it, is it a meta, A meta framework? Did you describe it as there? When we started the analysis we wondered whether we were trying to create one framework for all frameworks and then we looked at the frameworks, we realized they were all necessarily different and we remain so because they're meeting different policy requirements. So we'll define all the possible combinations and the tools to exchange, I guess if you want to call that a meta framework, it is. But we're not trying to create the framework of frameworks, if you like.

It's more a a, a set of possible criteria and tools to help with reasoning. That's a really useful insight about them being necessarily different. Yeah. At points. Yeah.

Alright, well thank you so much as Mate. Alright, thank you.