Thank you very much. We're excited to be here. And I appreciated the previous session because I think it really sets the stage for the importance of privacy. And we wanna talk about an area, which we haven't heard. A lot of people talking about is what do you do? How do you manage privacy in scenarios where people are not logged in, they're just using their device. So next slide. So you, you kind of heard who we are. All the only comment I will make here. I'm I'm George Fletcher is that Verizon who owned Verizon media recently sold Verizon media out. So we are now back to be calling Yahoo. So that's why you see all the purple and the Yahoo logos in this presentation.
Yeah, I'm I'm architect with platforms at Yahoo.
Great. So today we really wanna do two main things, set up a pro what is the problem for securing privacy for non logged in devices? And then talk about a proposed solution that we've been looking at, and we'll get into more of the details as to why do we even need something in this space? Next slide please. Great. So, so what is sort of the intersection of the context of what we wanna talk about today? We, we wanna talk about sort of this, this sort of intersection of a user who's not logged in using some application on a device that could be a desktop, a mobile device, right. And how is there privacy impacted by that interaction? You've, we've heard lots of conversations in the past about cookie banners. What does that mean? How does that impact, what do you do if you accept cookies? Is there anywhere you can go to find out what's happening? Right. So I think Mr. Smith talked about transparency, and I think you'll hear some of that in our presentation today as well. Next slide please.
So to, to make this a little bit more concrete, let's use the use case of personalization for a content delivery service service publisher. We can make it news. And, and in reality, right, I, as a user, you know, I might care about photography. I might care about tech. I might not care about entertainment. And so to some extent I would like that to be personalized. Obviously there are ways to do explicit personalization, but sometimes it's convenient to get it to be passively personalized. So if we want that experience, what's required, what are the technical bits that we need? Right. We obviously need consent from the user. We need a way to track the application instance, right? Remember the user's not logged. So we need a way to basically track their activity in that identifier. When we talk about securing the privacy, we're really talking about securing that identifier.
So you'll get a little bit more about that in the next slide. We need a mechanism then obviously, to convert the activity into an interest profile and algorithms to present the right stuff. So just sort of generic use case for personalization. Next slide, please, where this becomes tricky is in the privacy implications of personalization, right? If I built a interest profile about the user, right, the user should have the ability to download that interest profile or potentially delete that interest profile. Maybe in some cases, even update the interest profile. And in that context, when the user is interacting with the privacy infrastructure to take those actions, how are you insured that the person presenting that identifier, which is the only way, you know, how to link it to the underlying privacy information? How do you know the person presenting that identifier is authorized to do so? And so that really is at the crux of what we're talking about today is how do we secure that identifier? Next slide please.
So let's talk about mobile apps to start with, if I have a mobile app and it's a news app, how would I, how could I secure the, the representation of this use of the, of the app interacting with the platform? Right. Obviously there's a human probably on the other side of this, but the system doesn't know about the human. Well, thankfully in the mobile app space or rich desktop app space, we have two standards or two mechanisms provided for us that actually really help here. One of 'em is dynamic client registration, which is an open standard within the open ID foundation and part of open ID connect as well as in I ETF. And what this allows is the mobile app to register itself with the authorization server and pro and obtain a unique identifier for that instance of the app. One of the ways that you can do that registration is using PKI.
So you can register a public key, keep the private key in the secure enclave of the device. And now you have a very strong way to do proof of possession against that identifier. The other key element here is mobile app attestation, which is something provided by both Android and iOS it, and it allows the, the back end. So to speak, to determine who signed the app, that's trying to do dynamic client registration. And by combining these two, you can know directly what the app is and provide a secure identifier right through which then you can ensure the security when the user goes to the privacy system to obtain their interest profile. Next slide, please. The problem is that browsers have much less functionality. In reality, within browsers, we have two, we really only have one option for both tracking the identifier, as well as managing security, right?
And that's cookies. And on the cookie side, the me, the security mechanisms are basically these cookie attributes. One of 'em is HTP only, which means that the cookie data cannot be read by JavaScript running in the browser. The another is secure, which is basically ensures that the cookie is only transferred over a secure connection. I E T L S connection. You might put some of the new attributes of same site into here. You might be able in certain circumstances to use something like same site equals strict to reduce the exposure of where that cookie is shared, but that could also have impact on your implementation as to, you know, if the privacy systems running in one space and the, and the news site is running in a different space, strict may have problem problems. So at the end of the day, we have concerns with cookies, right?
They're just bare tokens, no proof of possession in certain cases, being bound to domains, which is really good for cookies to maintain their security could be problematic from a privacy perspective. So these is sort of the, the, the focus of what we wanna talk about going forward is how do we improve the browser situation? Next slide please. So just to recap as a user, I want to be able to access my personalization interest profile. And I want to ensure that I'm the only one who's able to access my interest profile, right? There's no logged in session. No, no authentication here. So how do I do that security and next slide. And so therefore the questions we really have are, is HTP only in secure cookie attribute sufficient, or can we do better? Next slide please. So to, before we get into our solution, I wanted to sort of take a, a small sort of look back at industry standards that have addressed this space, or potentially could address this space.
One of 'em is token binding for those who are familiar with it, it's a set of already published specifications for browsers that basically allow the binding of cookies to the TLS channels effectively ensuring that a cookie can only be sent from the browser in which it was set this set of specifications, like I said, is complete within the w three C and the I UTF the problem is, is browsers chose not to implement it? And so there isn't any implementation of this that can be taken advantage of the other option is a recent, well probably last year and a half proposal from Google on something called HTTP state tokens, which is sort of like a new way to do cookies. However, it's not really getting any traction either. There are some mechanisms in it that potentially could be used for proof of possession mechanism, but again, since there's really no work happening on it, we couldn't leverage this as well. So with that, I'm gonna turn it over to Deepak to walk through our proposed solution.
Hi, so our proposed solution, we call agent authentication. This leverages the crypto and secure storage support in browser and mobile apps. And using this, it binds the unique identifier assigned to user agent with the public private key owned by the user agent, using what we call it as demonstration of proof of position Depop Depop is an open standard and is an application level mechanism for send constraining or to access. And first tokens, it enables a client to demonstrate proof of position of public private key by including a of header in our TTP request. Our solution consists of two flows. The first is the user agent registration flow to obtain a secure agent identifier that is bound to the public key of the browser. The second is the user agent authentication to prove ownership of the user, the agent identifier let's look at the key aspects of registration flow.
The user agent, the browser in this case generates a unique public private key pair in the browser instance, and then makes a registration request with the authorization service requesting and secure agent identifier to that is that is bound to the public key of the browser, the authorization service in this case, validates the request and then gen dates, the agent cookie, which with the unique ID for the agent, and then generates a access token that binds the unique ID with the public key of the browser. Both agent cookie and access token are returned to the browser cookie stored as part of the cookie storage and the access token as part of the local storage. Essentially here, the access token is the one which actually maps the public key with the agent ID of, of the agent cookie.
So let's look at the registration in more detail client. In this case, the user agent, then it's a key pair, public private key pair. Then it generates a proof JT with the public key and go details. And the signature using the public private key pair. It makes a registration request with the authorizations server, with the deeper proof as the header, the server validate the deeper proof J using the public key and the payload. And then it Schutze a agent cookie by adding a unique agent identifier for the, for the browser and the expiry. And then it generates access token, which binds the agent cookie with the public key of the, of the user agent. So essentially the token, the access token that is returned to the browser has what we call it. If you look at the, the subject subject is the agent ID unique ID assigned to the user agent. And it has char 2 56 of the public key of the agent, which is the JT claim in the JWT.
So these are the access token agent cookie are returned to the browser and stored as part of the browser. So now let's look at how, you know, non logged in user personalization, you know, is enabled using the agent ID. So as a user, you know, accessing any publisher website or an application, for example, Yahoo news on the first launch, the it makes the agent registration request. And as part of the registration, it, it receives the agent and the access token, the publisher app, thens, the agent and any user Serer agent ID personalization profiles used personalization.
Now let's look at the key aspects of authentication flow, any service that requiring authentication can challenge the browser to prove that it owns the agent cookie. So in this case, the browser will generate a deeper proof token signed with a private key and passes it along with the agent cookie and the access token to the device authorization service. So there is a challenge challenge is the something that is passed by the initiator just to ensure that there is no CSRF attack. So the device authorization service first validates the of proof token and the agent cookie, and then validates the agent ID from the agent cookie and the public key that's part of the JWT is, is valid with the, with the data that is part of access token. If, if the data matches the service returns success or a failure assertion, as, as a token, along with the challenge that was initiated. Now, let's look at the user agent authentication bit more in detail.
The service makes challenges, the browser, the browser loads, a key pair from a store then generates a deeper through JWT as, as in, as in the same as in the registration flow, then it makes a device authentication request with authorization server passing, you know, proof, JWT, cookie access token, and the challenge. The server validates the deeper through JWT using public key and the payload. And then it validates the agent cookie signature and the expiry. Then it validates the ex access token and the binding between the agent cookie and the public key of the, of the browser. So if the, again, if the, if the, the validation is success, then the authorization service generates token with assertion that whether it is it's success or failure in this case, the token is, is a JT token. We use something called as AMR claim authentication method references, and, and the service initiating this request can check if, if that is set. And also it includes the challenge, which is a non that it can verify that it was initiated by, by the service.
So JWT token is returned to the, the client. Then any service can validate the JWT token and, you know, use ther claim to allow our deny access to the user. Let's look at how, you know, agent authentication enables the device data, download thus securing the privacy of non logged in user devices as a, as a non logged in user. You know, I go to browser and access say privacy dashboard and privacy dashboard service, you know, initiates challenges, the browser to prove that it owns that agent cookie. So as part of the agent authentication, the, the user agent, the browser in this case passes the cookie proof, JWT token, and the access token to the device, authorization service and privacy dashboard service in turn gets assertion from the authorization service, whether it was valid or invalid, if it is valid, then the service will request all the publisher back to, you know, return the data that is stored against the agent ID. That includes all the personalization profiles and anything that is stored against the agent ID. Then privacy dashboard service touches that data and, you know, present it to the user. Now I'll let, to conclude and share the key takeaways.
So thank you so much for staying with us during this presentation. The, the main things I think we want people to think about really resolve, revolve around cookies and whether cookies as Barra tokens are sufficient to mitigate the risk of exposing users, PII in these non logged in scenarios. And so if, if the data that you have is sufficiently, you know, low risk, then maybe, you know, secure cookies are sufficient, but we wanted to look at a way that we could improve that security. So that's really the, the thing I think we want you to, to take away is can you consider a stronger security mechanism, like a proof of possession mechanism to protect the user's private information, because even in these cases where the user is not logged in, they are still generating PII with the backend service and the, the aspects, as we mentioned in previous talks around transparency and allowing the user to understand what's happening, I think are gonna become more and more critical over time. And we want to ensure that as that happens, these use cases for non logged in users maintain just as much security as the logged in case. So thank you very much.
