Ready for shopping season: Verifying and authorizing buying agents

My name is Tim Simeonov. I'm a Vice President of Innovation, Engineering, and Experian and I'm leading Experian Agent Trust and in the next 20 minutes I'll tell you a little bit about the landscape and also do a live demo and go over what we built on Cloudflare for this Agent Trust. A lot of numbers here but a couple big ones. Over $1 trillion of e-commerce through agents by 2030 and as Matthew this morning was sharing that even he was conservative in his prediction of how much of the traffic would be bots. It's 60% of the traffic now on the Internet is bots and merchants and service providers are struggling to understand and know how to participate in this newly coming agent e -commerce. Should we stop or let the bots go? Regardless of what the numbers are number one question is can we trust this agent? When we talk about agents there are six places where things can go wrong and can break. First is the identity gap. Do we know that this headless browser request that comes to us has an agent that is a well-meaning and capable agent? It's also authorized by a real human to do an e -commerce transaction. Is the intent really focused and documented? Is it followed? I asked for running shoes for $140 and the agent selected and returned shoes for $180. Visibility gap is a major issue that is still being solved but all the merchants and the e-commerce sites want to keep and maintain the relationship with their customers. That's a goal to them. So now if the new customers are agents how do they know that they should allow these agents to conduct e-commerce on their site and also keep the relationship with the customer going? Authorization. Is this action permitted? It's not just the $140 of shoes that were authorized but it is for that specific moment for that specific merchant and cannot be replayed. It cannot be reapplied again. The risk. There are many aspects to calculating and managing risk in this whole transaction example. Is it authorized by a real human? Is it conducted by a capable and trustworthy agent and a platform? Is it secure? Is the payment in place? Is it accurate? And then at the end the liability gap. If things and when things go wrong, chargebacks or returns or fraud, what happens? Who is responsible and where are the records? Where is the data that helps us resolve that potential liability gap? At the end of the day our goal is to enable agentic e -commerce and to do that we need to recognize the agent, verify the human that authorized that agent, bind them together, that is what we do with agent trust, score that session and also keep the record for liability potential disputes. Currently the merchant has no longer a binary choice whether you block the traffic or you let the traffic in but with letting the traffic in you're also allowing potentially a lot of fraud and misuse. With Experian Agent Trust we score, we bind, we verify and give that assurance to the merchant that now in the HTTP header of every request I get a token that I can inspect. I can guarantee that this token is cryptographically signed, it is intact and it gives me that assurance that there is a human and agent binding together and it's verified and I can let that traffic in and participate in this 1 trillion dollars by 2030 additional opportunity. Now some of the challenges more on the technical side. This is a typical HTTP header. What is happening? The merchant is seeing this request coming in and they see an IP address but is that IP address something that they can trust? Maybe it's a VM that I just rented this morning. Then there is a user agent description again up to the agent provider. I can say it's the most trustworthy agent in the world and then a claim. All of these three attributes in the HTTP header are pretty much provided by the agent provider so they cannot be trusted, they need to be verified. There are four areas that need to be solved and authentication is the first part where web.auth which was altered by Cloudflare and Google partnership is verifying the signature providing the assurance that the origin is right. But then the next step is attestation which is what we call KYA or know your agent and that's where Experian provides Experian agent trust. The next level is the KYA plus pay where in addition to know your agent we provide also the payment and then last but not least is the trust score. The trust score can mean many things. There are several layers of the trust score and the trust is trusting that it's a reliable platform agent and human together because in that fraud matrix you can have bad agent, you can have good agent and also bad human, a bad meaning human right. So there are many aspects to trusting and calculating the score and next I want to show you a demo where we go through these steps and I'll go into details of what happens behind the scenes for every single step. Okay all right so what you see here is what we built on Cloudflare and I'll go into more of the durable objects and the workers and everything else that is behind this but we split on purpose the screen in two. One on the left is what typical shopping experience is you go to your Muse or whatever chat GPT chat platform and you start discussing what you need. On the right side the bigger part is where I'm going to show you behind the scenes what is happening step by step to make sure that this transaction is actually secure, authorized, authenticated and trustworthy at the end. So first I would say okay I want to find trail running shoes under $140. By just this simple request and two options to return from the merchant behind the scenes a lot of things happened and they happened very quickly. So you can see on the right hand side in the activity console the first step was web bot auth. So this is the standard that helps ensuring that the request is signed properly, it's verified and it can be trusted. The verification is behind the scenes has a lot of details but at the end of the day through the public key you can verify that this was signed properly by in this example trailhead.example and you can see the key and the tag and everything else. There are seven steps that go to verify all of this and you can see them listed here. Again the activity console was meant to illustrate what is happening behind the scenes. All of this is working code running on Cloudflare. After we verified that now we know who we are talking with and there was no tampering with the payload and the HTTP header. The initiation of the KYA or know your agent starts and this is where the request comes to Experian agent trust registry and we verify that this is again think of the two things a good agent and a good human right a verified human. So we go and we perform different checks first on the platform where the agent came from and then on the human binding. The human we can go as frictionless as just an email address we check the email and Experian has the largest identity graph in US. We check the email and we verify that this email really belongs to the shopper. The next level is if a phone number was provided it can be email and phone and the KYA can be as light as email or as detailed as all the way to even document verification. We can go email phone verifying on the phone and on the phone device a link can be sent when purchase starts to occur that verifies the behavioral analytics running on that link that it is a human it verified the link. It can also verify many different signals that are coming from the actual sim and actual phone device but it's up to the merchant how much friction and how much trust they need. So again it is as light as email and as deep as all the way to document verification. Once we have the registered buyer now we have that human to agent binding and we create that token and that token is a small piece of JSON code that is sent in the HTTP header and that is how the CDNs the firewalls and also the merchant ultimately security system can inspect and check that. Now once the KYA token is issued the merchant returns the result. Now I need to select which pair I want. I'll select the size and the color and add it to the card. Now once I place the order and authorize it a lot more happens behind the scene. So you saw that now we initiated KYA pay token. So now behind the scenes what happened was we communicated with the Visa network which has in this case Visa as an example has their own Visa Vick protocol and it issued a temporary one-time credit card number to be used exactly for that amount exactly on this merchant for that purchase. That is live for a few seconds and once it is used it cannot be reused again. Once we get that we continue with all of these details and by the way the KYA is an open standard you can go and see all the details to a site called kyapay .org. It is a consortium of different players that came together to build this missing piece of the e-commerce and you can go and see a lot of examples and the details of the KYA and KYA pay token what information is carried and what information you can rely on as either a merchant or as an agent provider. But going back to the demo now what happened was that the order was confirmed and everything checked out. So far that was the happy path, sunny day, there is no fraud, there is no shenanigans, everything worked okay. For the purpose of the demo we tried to show also four bad outcomes. Even with this infrastructure things can go wrong. So the first example is when we have an authorized bot. Again I select the shoes and we go and this fails once we initiated the KYA and we saw that wait a minute this bot we have zero understanding where it comes from and even if it is a well-meaning and authorized person this bot is not trustworthy and then it's blocked or in this case no human was found. So the email that the human provided failed. So it can be two scenarios it can be a bad bot or not verified human I should say. Now I'll reset this and try to show the next one. Now one challenge can be so-called card drift. You started with one amount and then somehow something broke along the way and you authorized for $140 and at the end before checkout the card has $180. So again the same example of the shoes it goes well all the way to showing you the options. I select these shoes and add it to the cart and then I place the order. I authorized $157 but what is happening behind the scenes here is that there is a cart mismatch and the mismatch is that now somehow this got repriced at a different price. So again behind the KYA pay there is a mandate there is the merchant there is the amount there is even the the SKU of the item can be included. So before this is authorized to be fulfilled one last check is made and in this case the cart drifted. Another example is a replay attack. So when we go and again in the first phases of the WebBot Auth those seven steps there is also the notion of a nonce. That is the one token that kind of is one-time use and this is where the power of durable objects and Cloudflare provides this very easily for us to make sure that that nonce the one was created is unique and it cannot be reused. So the app created a nonce and then the merchant checked and saw that okay this nonce is already used so you use that to place that order initially. Now there is a replay attack and somebody is trying to place that order again. It will be stopped because the nonce would fail. The last example of what can go wrong I want to show you is now talking about the trust score. Again the trust score we have three types of score. We have light score, medium, all the way to the extended score where the merchant can asynchronously call Experian Agent Trust and request the score. When they request the score we can return all of the attributes so their internal security system can ingest those attributes and make the decision not just based on the numeric score but based on the rest of the attributes. And you can see here is that when I select the shoes and add to the cart it's authorized but now the score is less than what the system of the merchant expected and it is blocked. If we can go back to the slides. Okay so what we went through is these four steps and what went wrong but once everything goes right then 7 of 7 and the agent and human binding is confirmed and the purchase is created. I want to end with why Experian should play a role in this ecosystem. Experian is a well-known highly regulated public entity that has earned and keeps earning the trust of millions of us whether it's for credit score or for risks with business scoring. We have the largest identity graph. We are an independent and highly regulated entity so we believe that we add value to the ecosystem by just being that independent authority that can help both the customer and the merchant in this case to trust that transaction is legitimate. And with that I think we're out of time but thank you so much.