I'm going to stick to the timeline. It's a privilege to be here and present my topic that comes to my heart. I've been working with privacy and I have done some standardization. I'm part of the Swedish Institute for Standards and I'm funded by the Stand ICT, which gives grants to individuals that want to drive the goals that EU has around privacy. Before I get started, a lot of the presentations and the discussions are under the user shall have the control over their data. We've had death by cookies. You know that. You just click. You just agree.
I'm going to share my data without really thinking about that step. And I'm concerned with the wallet. There's a lot of social engineering and you hear about scams that are running around. There will be attacks trying to get you to agree to share your data. I'm very concerned with that. And organizations that own the data, like health care, if they don't can't trust that the wallet will do the due diligence to share the data, they're not going to put their data. They're not going to accept to let me.
PID is one thing, driver's license and so forth, but some groups like health care will not put their data on the wallet. And this is something that I'm trying to address with the standard that I'm driving in SEND. I call it the access control of the personal data. And I'm going to give you an overview of what are the steps that are needed to clarify what needs to be done in the background before that last step. So there are things that need to take place before you click that.
OK, there might be warnings and I'll touch on that. And there are some cases organizations trying to address that. How do we give consent and under which conditions? So I think you've seen this diagram more than 100 times by end of this presentation. It's basically the wallet unit and how it shall have the control. So there will be data in this wallet that will at some point you're going to click and give an access. I'm going to plant the seed of a concept that I'm trying to drive through the standard. And it's a wallet asset control decision engine.
Working with standards, you like to make acronyms. So I'll be introducing a couple. One is WAIS. So this is the engine that would come with an input. And I'll describe what this input is. There's a metadata and data information coming from the relying party. And the output should be very clear, blocked. There's a policy that doesn't allow this to be shared. Or not recommended to be shared. And here it's a sensitive part because you're really driving that individual has that final decision. But there could be a recommendation, don't block. And the third, perfectly fine. Granting is OK.
And I'm going to give an example of how this might look like from a user perspective. I'd love to make it interact, but I'm strict to 20 minutes. So if there are questions towards the end. What kind of assets are we talking about? And I just wanted to clarify. It's not only the PID with the driver's license. It's your QEA. It's like proof of age or employment. It could be wallet user attributes, like driving privileges. And I try to cover not only the PIDs and the verifiable potentials, but what's in the wallet itself. Because you're creating a transaction log of all the interactions you have.
That will also be stored. I've heard of cross-border. I'm going to look at your wallet and see who have you shared your data, what services have you seen. So the access of that data also needs to be made clear. So these are all the assets that I'm trying to cover. Another acronym, wallet held assets. It used to be attributes, but then we realized, wait, they're more than just attributes. So they're all different types of assets. And when we look at the Implementation Act, it highlights several risks when it comes to the wallet. And I list them a few. It's the data theft. You steal the phone.
The particular one that I'm interested in is this data disclosure. Because that's the one where you're going to get the social engineering to try to get to that information.
I mean, we have technically capabilities to addressing many of this. Another one that's very important is the lack of accountability. Who am I sharing with and how do I track and how do I inform that somebody's using my data incorrectly? And the lack of traceability. From a security perspective, great, we're putting all this data in the wallet, I'm sharing it. But from a security perspective, you need to trace. You need to track who did I share under which conditions. So the conditions or the terms for sharing need to be very clear up front.
Now I'm going to introduce what influences this engine, this waste. So there are two sets of data that will influence. And this is a terminology that is challenging. When you look at Implementation Act and you look at the specs of OneID Forums, specs for variable credentials, there's all this data that needs to be fed in for a wallet to finally make a decision to share. And I try to articulate what are the wallet-held access control metadata. Think of provenance, the data that is collected that follows the attributes. And that is collected in the wallet.
While the relying party presentation request is what is on the request. The first interaction, what information are they passing? And here I do a breakdown of what are the wallet-held, I call it WAM, wallet-held access control metadata. And then we have two sets. One is the disclosure policies and one is instructions. And I'll explain what those are. From a disclosure policies, you might have your user preferences. So think of, for research, I will share, no problem. For advertisement, I don't want to share. So you'd specify that preference. The wallet disclosure policies.
This wallet might be issued by a specific government. And they might need to have certain policies for sharing or not. And then something that's coming through the Implementation Act are these attribute-related policies. These embedded policies that will dictate when to share information or not. And this is a polemic because many are saying that you can't share without being registered and so forth. So there are challenges with how you implement. But I'm describing from a standard, what is it that controls?
And then through regulation and national decisions, you decide what are the policies that you set up. Now, from the relying party, I forgot the instructions. Instructions, think of them as, okay, there's a policy that didn't pass. You need to get some instructions to the user as far as guide them in the decision. I wish I could do like a checkbox on the instructions. Because then you say, I've read and understood the consequences of sharing to a relying party. I don't know who it is. You're liable to lose all your money if you do this transaction.
So the instructions, I think, has a very key aspect to it, associated. And then comes from the relying party. And then here we get the relying party authorization. Often we talk about access certificates that has been introduced this year and it's being discussed. The relying party characteristics. So what kind of, how do they want to use your attributes? They're looking at this registration certificate to say these are the attributes that are going to be used for a specific purpose. And these are optional. I should have changed this. Relying party AAL, it's lower expectation.
The level of attestation. So when there's a request, how do I know that this is actually the individual that is holding the phone and sharing their data? So you'd be specifying that. And something that comes to heart is this processing information notice. It's a standard that I've been lead editor 27560. Having time, I'll cover it a little bit more.
This is, think of a privacy policy, but in a structured form that can be shared from the relying party and say these are the conditions. Because it's a metadata or in a format that's machine readable, connected to the notice, registration certificate, access certificate, and the policies, you have everything that's needed to make this access very clear. And I have a diagram that will kind of put things together to make it work. So bear with me. This is the slide that goes through what happens in the wallet.
So I'm going to do a flow of the steps that go through in the decision to share your information. And initialization. And I'm indicating in red what are things that would stop from sharing data.
So, for example, when I, and this might be done prior to relying party requesting information. Integrity checks. Seeing has it been rooted? Are there hacking accessibility providers? Is there something happening in the environment that is a risk for the user and the data disclosure? And so that would be one of the first steps. And that would potentially block the whole request. This is not a trusted device. Next one. I like that song. Can we play it during the whole presentation? It's relaxing. Then we have the step prior to the user making the decision.
This is the brains of trying to make a decision, the wallet instance processing. And this is where you're using all the metadata and the attributes that are being passed by the relying party to make a final decision.
And these, did you, the relying party, is it trusted? Is it part of this registry certificate, for example? Yes or no. If it's not, in some countries they might say block. You cannot access this information, this PID, because you're not registered. And also the attributes. They might be asking more information that really they're permitted. So that will also be highlighted. And it's very important to educate the user that you shouldn't get access. So it's a recommended block. And then you have the user access preferences. This is another one for recommended blocking based on your preferences.
And then comes the step, the final decision, where the user has the option to bypass any of the recommendations for sharing. And then you also have the option to review the privacy information notice, the details. I don't know, does anybody read the cookies, you know, manage and then see why they share? Anybody? I've taught my wife and she's learned to press manage and then at the very end reject all. So she's pretty illiterate. So we need to have the metadata in order for the people who want to get to that information can also access.
And then finally you get, and I'm going to do one more slide to explain how this, what's presented. I'm not a UI guy and it's not as sexy, but you typically have your grant or not grant. But then you have this warning. So those are the ones that you bring up any instructions. And I'm not saying this is, you just show that warning.
It's, there's something going on. Something that is not recommended for the user to share as well. And also very important, who do you contact? So the information that's being collected and hopefully registered so that we know who they are, their identity of the company asking for that information. You can contact an authority to say, well, I got a warning. I don't really understand, but I have somebody to contact. So I think that's an important aspect in this. We need to be proactive against bad actors in the industry. If the best security people to detect something as wrong as the user.
I'm not saying that every single time you get a connect, they should analyze and look into. But the collecting of that information is very important for addressing a cyber attack at a scale. Because I heard the presentation. If you attack one phone, you get the data. It's not that bad compared to a silo in the cloud. But if there's a concerted effort to get information, it's very important that the authorities get the information. And then from a security perspective, you need a log of the transaction.
And you've heard of the privacy dashboard where you get all the transactions that you have performed. Yeah, this is the last animation. If you want to take this picture, this is the one.
Yeah, I'll even pose. So, yeah, exactly. I take many pictures, too. So I understand the need to get the right slide and right moment before they go to the next slide. So the transaction log would then...
Yeah, exactly. This is the point. So you have the transaction log. And this is, again, you have the contact information. I want to withdraw. I don't want to keep it in this company that has gotten access to my information. So that's very important for my usability as well. So this is what I'm trying to cover in the standard. I'm co-authoring with a couple of other people in SEND to specify what are the requirements to fulfill in order to be able to make a safer, more trustworthy ecosystem. I'm not specifying on the UI part, but it's more on the information and the requirements to fulfill.
So when you go for a certification of a wallet, they would need to fulfill this. And I'm also trying to promote, and this is something you can contact me, creating an open source component of this Waze engine. Because there's this whole interoperability issue. And there are many different standards trying to, okay, talk to each other. One country wants one way and another for another country. And I would like to see that this part is actually developed openly so that it can be reused across EU and maybe internationally as well. So how could this look? So I had a couple of discussions last week.
I had a conversation with NIST with my work on 27560, this consent record information. And this is your typical attribute list. And I like the idea that you iconify. I like what Apple has done with the privacy labels. That helps to depict the information. So it's a good positive, but it doesn't give you much information. And I'm going to contrast with Australia Roads. They've done an initiative to create a privacy comment. It's a very noble action. I'm not saying this is what needs to be done.
I'm just giving an example of how, if you have the right information, the metadata, you can be able to, when you go and buy a washing machine, you like your energy efficiency, A, B, C, and D. If it's F, you don't want to buy that equipment. It's the same thing with privacy information. And I don't understand from that, from Japan, that they do have something in that area of some form of labeling to say something is not right here. Or not that it's wrong, but it's how they process. Where is the data being kept? And you probably can't see this.
If you contact me, I can try to get you together with the author to explain how the variables that are used to make a rating system, something to help educate the user. Without that education, you're going to death by cookies. I don't know. I think even websites should be having something like this. This website, it's a little suspicious how their story. And the third parties that they're sharing with, you really don't want to use this website. But there could be a user preference. I don't have a problem to share my personal data or my user behavior. So you should have that control as well.
Something else just to highlight is also the ability to know if your relying party is registered or not. And that's something else that's very important. From a usability to understand, when I'm sharing, I know that I'm talking to a registered relying party. So this is a food for thought when it comes to how you share your data. So the last slide, I'm going to do a little deep dive. I'm kind of proud of this standard that was published in 2023. There's a revision of it. Consent is just one of the six lawful bases of sharing your personal data. And we want to expand it to include.
Basically, this is a structure of the fields that are needed to create a record of sharing of your information. So think of it as a privacy notice. There would be a record. And it's divided in these components. I'm not going to go through all the details. But I thought of just showing the overview. And then quickly just kind of touching on. And this is a complicated part. Purpose. There's primary purpose, secondary, and third, fourth.
I mean, there are many different purposes when I share that information. So being able to capture that. There's primary, secondary, third. And who is the ones that are, is it a third party that has a secondary purpose to access? So the health case. That's fine. You'd probably have no problem for that purpose. And you have a user preference to say, yes, I'll share with the health. But not for advertisement. Or there might be a revenue sharing where you get a couple of cents.
There was a business case where they said, you know, you're fine with sharing with advertisements if I do get a revenue share. And then you have all that information tied to. The details of how to contact not only the controller, the relying party, but also the third parties. And also we have the authority party. So who do you contact when something goes wrong? And then under personal information, I highlight what is sensitive. This in the registration certificate also covers. But it's in the standard we also cover that part. And just going through a couple. I ran out of time.
Are you guys okay? Just a couple of minutes. Almost there. So it's where you're storing the data. That's also a very important part from the cross-border requirements and knowing where the information is kept. How long is the data going to be kept? Where is the jurisdiction for the rules that you're complying with from the privacy? And also your rights.
The GDPR, you have the right to withdraw. So the transaction log would have the opportunity to how do I contact to withdraw. That's mandatory. But there are other privacy rights that you also can exercise to get that data. And then this is a ‑‑ there is a life cycle. So you get a notice. That would be one event. The point you do the consent to whatever lawful basis, you would make a record. And that's where you have the transaction log. This is now the point. If you wanted to see this, this is the picture moment. But okay. You guys got it.
And with that, I thank you for having the opportunity to present and being your last speaker. I'm glad you survived all this whole week. So thank you. Thank you. Thank you. Thank you.
