Delegating Digital Identity: Enabling Trusted AI Agents in Transactional Flows

Hi, and welcome. So, as I said, we are going to talk about how to delegate digital identity, and this will be in high-demand e-commerce agentic flows.

So, the reason that we are three people on the stage, three companies, is because we are doing a proof-of-concept together, proving that we can handle agents in these high-demand events that my company is doing. So, ticket sales, iPhone drafts, stuff like that, and then handle the whole journey through agentic flows.

Oh, sorry. Can I go back?

So, again, my name is Morten. I come from Queue-it. And I just said what we are doing. Jan?

Hello, everyone. My name is Jan. I'm leading the development of SVX, a platform where we help our customers comply with regulation and technical standards around verifiable credentials. Aki?

Hi, I'm Aki from DNP in Japan. We are one of the largest credit card vendors in the country.

So, I'm the product lead of our verifiable credentials service. I originally come from mathematics and cryptography background. Thank you. All right.

So, the common theme in this presentation will be about fairness. Because online fairness is much harder now than it was before. Because now there's a lot of agents out there, and they are maybe acting on behalf of a user, maybe they're not. And why this is important to us is that in our company and in similar companies, we see a lot of this traffic.

Last year, we saw 35 billion visitors going through our platform. That's quite a lot.

And, for example, we saw recently an event that we were having with 12 million visitors just in one event. In that event, we also blocked 8.6 million bots. By blocking those bots, we gave the real humans a chance to, a 19 times bigger chance of getting what they wanted. But that is changing now because users are now delegating things to agents to buy things for them. It was fairly easy, or at least a known problem before for us, because we knew that humans, they were good, and bots, they were bad. But those lines are blurred now, and it's about intent. So what is it that is behind this?

We need to verify the intent in order to ensure fairness, and that's also if it's just bots, agents. The traffic last year, automated traffic increased 8 times faster than human traffic. Cloudflare reported that they saw doubling in traffic in January. And it's predicted that one fifth out of all end-to-end purchases will happen by agents in the upcoming years. So that's a completely new landscape. So we need to architect for this web where there's a digital butler, someone who is doing something on behalf of a real user. And Jan will talk about the POC and the technical details.

During this POC, we're essentially asking ourselves constantly two important questions. The first one is, how do you treat an agent fairly if you don't know who's sending it? And the second one is, how can an agent actually order and pay for the human? We already know from the literature that impersonation is a dead end. It muddies the waters, creates all kinds of problems with accountability. So instead, we turn to digital identity and more specifically to verifiable digital credentials as an underlying technology that we identified that could solve this problem.

So we use it for the user to prove their identity and allow the agent to represent it. But also, we capture the consent of the user and give the agent a mandate to order and pay for the item that they want. So next up, Morten is going to demonstrate this.

Yeah, so maybe not all of you know about waiting rooms because maybe you have not bought tickets to a very popular artist or sneakers that are in high demand. But there's a lot of these going on. And what we're going to show here is a normal flow where a user wants to buy some shoes. They're in high demand. They're protected. So they go into a waiting room. After that, we will show the POC how this is done by agents.

So first, we'll show the normal flow. There's a user. He sees that there's some premium sneakers. They're protected. He goes into this waiting room. This is an order to make sure that it's not sold out when he gets there. And all the users are not crashing the service. So now he can go in. He knows it's his turn. And he can buy the sneakers. And this is a normal checkout flow. But the queue is the essential part here.

Yeah, maybe it's important. The point where the user has friction is this queue as that can take anything between one second, two minutes, but it could also take a couple of hours. And the user has to wait. And then when it's their turn, they then get a specific time slot where they can do the action. So now we think agents can actually be quite useful here.

So here, the user is no longer using the website, but they're using a very traditional or at least AI traditional chat interface. They're interacting, prompting the agent. They're getting the information, identify the product that they want.

So far, nothing special. But here is the exact point that the agent also identifies, okay, this is an item in high demand. And this is where our POC actually focuses at. And we ask the user to present their identity.

And also, as you can see here on the right, to consent to a specific transaction with this specific vendor for a certain amount. And that will allow later to actually pay for the item. This is using the standards that we all know and love. See Joseph here from OpenID. So we'll be happy to hear that we're using that. The user shares the credential. And from then on, they can step away, knowing that the agent now takes care of that. They can have lunch, do something fun. And the transaction will be them receiving the shoe.

So now what we actually, we're going to give a little bit more insight in what we're doing. So the agent, shopping agent, of course, sits in between them and the webshop. They're not using the UI. They're using an MCP server.

In this, here we are using Shopify. Shopify actually have an agentic storefront. They're using an MCP server where they defined a couple of actions. So we're using, we're leveraging those, that protocol. The agent searches the catalog. It gets the product information to then show that in the interface. The digital ID interaction we come to later. But then here, once that is done, the agent now has the mandate. It knows who it is representing. And then is waiting in the waiting room. Receives a token to queue. And then is able to execute the full flow. Even more details.

For those interested, we're not going to go through this in whole detail. But feel free to download our presentation and investigate it and ask us afterwards. I'll just highlight some things. The first part is the MCP server interaction. Already covered that. But then in the phase two, you can see how the agent identifies that there is a queue. We then do this open ID for VP interaction where the agent requests the identity. The user provides that. And we're also using a specific thing in the standard which is called transaction data.

To then sign the consent and provide, the user provides authorization for the agent to complete the flow. We're using an intent mandate. Aki will give some more information about that.

But here, maybe also interesting to point out. This is where we're starting the interaction with the Qubit backend systems. As Morten already said, it's incredibly high demand. We don't have time to go online calling endpoints. No. We think that these credentials actually, because they are self-contained, they can actually, it's a good strategy to allow this load and do these checks in real time. And in phase five is something that we are just starting. But that's where we will explore how to do the actual payment, which is something that the AP2 protocol is explaining.

But Aki will tell us more about that. Yeah, thank you, Morten.

Next, let me walk through why AP2 mandates provide a foundation for trusted dedication and SPOC, especially in a human not present flow. In an agentic commerce flow, the user needs a safe way to authorize an AI agent. Merchants need a verifiable signal to understand who the agent represents and what it is allowed to do. And fairness requires enforcing one principle, one place, even when multiple agents exist. AP2 provides a standard way to express this dedication.

In SPOC, we use the intent mandate, which captures the user's authorization for the agent to act on their behalf. Actually, in the new version released recently, a different mandate format is required.

However, since our implementation and integration is based on old version, so I hope you'll understand that. Next, AP2 mandates are implemented as verifiable credentials. They are self-contained, meaning merchants can verify them without relying on OpenID Connect. They are merchant-bound, preventing cross-site replay, and they support selective disclosure, so only the necessary information is shared. This model is ideal for AI agents.

It cryptographically proves who the agent represents to find the scope of what the agent is allowed to do and prevents multi-agent abuse by binding the mandate to a signal principle. So, in our POC, the user issues an intent mandate through the identity wallet. The shopping agent presents this mandate to merchants, which verifies it and enforces fairness based on the principal identity. This ensures that even if multiple agents exist, they all map back to a single human.

So, that's how AP2 enables cross-site delegation for AI agents. With this foundation in place, Morten will now walk through what this unlocks for users and merchants.

Yeah, so what is the future of agentic e-commerce? So, there will be users, and they will be delegating things to agents, that's for sure.

So, we need verifiable identity. We need to know who's behind the agent, and we need to know what mandate they gave. When we have that, then we can make sure that we create fairness. And one interesting thing we have learned from this POC is that to create fairness is not the same as treating everyone the same, because normally you shouldn't log in to buy some shoes. You should just click on the checkout and then put in your details. But in order to have all the automation that an agent gives you, there's a small friction point, and then you can get the automation.

So, we will probably, in QA, we will probably allow people to go into the queue if they use the normal website without authenticating themselves. But if they have an agent, they need to go to the MCP server with the agent. But that's a small price in order to get the things you want without waiting and without having all the troubles typing in stuff. It's just being done automated. Yes.

So, in this POC, this is a sort of a takeaway slide. We looked at how a queue that's consisting out of different actors, humans, non-humans, can work. We want to weed out the bots, and we want to allow the agents to be let in, but then treated fairly.

So, not separate agent and human queues. No, it's one queue within verifiable digital credentials. And these surrounding protocols are a great starting point for this, and they can actually help this. I hear a lot about theory, but the root is in practice.

Like, we are actually coding. We are testing this together with Kiewit and DNP to see how this could work. In the next steps, we are looking at the end-to-end flow. I already spoke to you about the phase five of the sequence diagram to do the payment. We also want to see on agentic identity how that plays a role together with the human identity.

And, of course, we want to mitigate any privacy risks. As I didn't mention that, but with Kiewit as a system, it doesn't need to know who you are specifically. It just needs to know that it's a human behind it, and it somehow needs to be able to then identify them so that it is treated fairly. If you're interested in this domain, if you're involved in it, in the payment side, or any of the things speak to you, then, yeah, please come and talk to us and contact us. Thank you. Thank you very much. Thank you very much. I think there is some time left for questions, maybe one or two.

I already checked the online section. There are no questions there, but still, if people in the room have a question, then I think we can take one or two. Let me quickly get the microphone from over here. Just give me one so I can hand it over here. It's just the first row. That's great. That helps me. Thanks. This looks like a very interesting and promising POC you guys did. I'm curious to understand the definition you gave to fairness, because that's a word that came back quite often in your presentation, but I'm not sure I'm grasping what you actually interpret as being fairness in all this.

And the second side of the question is around the linking to a human, which I think is essential. But how solid or robust is this in case of legal complication?

Meaning, how do you make sure that the human behind it is then hold fully accountable for the transaction, especially when they could be fraud? Maybe I can take the fairness part. So that's the whole thing about the queuing system. It's a first in, first out. So if we cannot ensure that the agent is a real person, then there's no reason to put them first in, first out. We need to block bad actors. So that's what the fairness is about. So that's what we have been all about for a lot of years, to block bots. But we cannot just block bots now. We actually need to look at the intent.

And maybe, yeah, the accountability part. I don't know if you're aware of how much you're aware of this AP2 standard, but that's actually something specifically that they are trying to solve. It was developed by Google, the first version. It's now moved, I believe, to the FIDO Alliance, if I'm not mistaken.

And yeah, we're using that work because that's something that they are trying to solve. Like that when you pay, that you can be held accountable. But we are just, I mean, we are looking at those things to then help solve that.

Okay, so thank you very much. And unfortunately, time is already over. So thank you very much. Raise your hands for those presenters here. And for all the inside information you're sharing here.