**Session Date/Time:** 19 Oct 2026 17:00

[00:00:14] **Rifaat Shekh-Yusef**: We'll start in few more minutes, maybe o five. Hello? Hey, Mike.

[00:00:50] **Michael Jones**: Rifaat?

[00:04:29] **Rifaat Shekh-Yusef**: K. We'll we'll start in a minute here. I see Mike here. Is is Meiling here? I see. Oh, yeah. Okay.

[00:04:38] **Michael Jones**: Yes. I'm

[00:04:39] **Rifaat Shekh-Yusef**: here. Yep. Hi, Meiling. Will you be presenting yourself or somebody else?

[00:04:46] **Meiling Chen**: You can present the slides for me.

[00:04:50] **Rifaat Shekh-Yusef**: Yep. Okay. Okay. K. Well, okay. Let's get going. I think we have enough people here to get going. Okay. This is the Note Well. Again, a reminder that Note Well applies here. The Note Well defines, how the, the IDF conducts its business. This includes, how you, we conduct our behavior, how we discuss things, how, IPRs impact things. So if you're not familiar with all of this, make sure you you get familiar with this. It's it's important. So today, we will talk about agent authorization, use cases, and gaps. And we still have one more interim to discuss next week that will conclude our our interim before San Francisco. So that's our agenda. So we will have two presentations. A meeting will start, and then Mike Jones will will follow after that. We will allocate twenty minutes for each one, and and then kind of open it for questions and discussions. Any questions? Okay. Okay. Meiling. Okay. Hey. One second here. Let me... I... I'm gonna hand you the control over the slides. You can progress it yourself. Try it?

[00:06:40] **Meiling Chen**: Okay. I I I got the control now.

[00:06:43] **Rifaat Shekh-Yusef**: Okay. Perfect. Google for it.

[00:06:48] **Meiling Chen**: Oh, okay. It's a little slow. Okay. Hi. I will start. Mhmm. We are here to present our continuous work on agent authorization use cases and gap analysis. And we have updated the latest version to therefore. I'm not sure if most of you have read the latest draft, so I will give a very brief introduction. The therefore version has included 13 use cases, and we will add another use... Another new use case from for next version. And since last two, think, we have provide a very detailed analysis of the... Each use cases. In section three, we summarize the three main gate, the ads... Consolidation contest gate, the delegation chain gate, and the mass modification gate. But for today's interim meeting, we will just focus on the section 3.5 that the consolidation context cape and partly from section 3.2 of the jet. That's the delegation chain cape. So let's start with our first use case. It's it's a very technical personal digital assistant. But in this case, it's a telecom sales assistant. We try to mobile and then our assistant agent as Lynch agent. Until now, the Lynch agent have served 800 millions users. The follow here is that user can consult Lynch about service print suggestion. So that's... Suggest a service print for me. That's the user's intent... Initial intent. After the user make a choice, the intent needs to ask for permission to activate to the plane x. That's the link should do the rec... Of the plane. That's their formal authorization request. This process expose our first major problem is how can we ensure the correct... Correct conversion from the user's high level, sometimes weak intent into precise and secure authorization request. An error in these translations could lead to the wrong service being activated. So we call this the oscillation contact escape. And the second use case is is also shorter problem I have sit in the use case one. This is a use case a... For agent payment is the UnionPay agent set in a comp... Complete procurement contest. The process begins when our user approves our, purchase order. This approved established the user's purchase intent in advance. The agent then take this approved purchase order, and the initial is the subsequent payment request to our merchant. The critical part here is that the settlement system must verify their incoming payment request is directly related to the preapproved purchase order, which represents the original intent. So this, again, highlights the authorization context gave you. The current question is, how do we ensure the subsequent and authorization request, like like, the new payment? They, is very favorably linked to their prior intent, like like the the initial approved purchase order. The use case three brings us to a more complex and cross dominant scenario, smart home, and the elderly care. Or, like like, the child the child is the user. The user tells their home agent a very broad intent. Just look after my parents, the AI agent. I mean, the home agent here must break this down and request, serials of specific permissions, such as reading house records, setting medical, medic reminders or using smart moved camera for for the... For detection. When the robot detects a four and arrives an errant, that errant may need to be sent to another domain to a separate emergency response series. This introduces two key in charge here. The first is how to accurately convert the very broad intent just like looking after my parents into specific and more granular permissions. The second came... Challenge here is how do we preserve our original intent and authorization context as the task and

[00:14:07] **Rifaat Shekh-Yusef**: the data

[00:14:07] **Meiling Chen**: across different system boundaries. So we can see in case three, they are different from case one and case two is because there... They face both authentication context gate and also the delegation chain gate here. Our first use case, chip planning, they have mentioned multi agent system. Chip planning, we are so familiar with the example. We heard heard too many travel examples. So I also print it here. A user gives a very high level intent just like help me to plan a five day trip to Chengdu. The main agent, agent will receive this intent then. Trans... Translated the intent to the task and request general authorization to book flights, hotels, and also attraction tickets. The key in trying to hear is that the agents must decompose the large task into into the small task. So from the function, we... It needs to delegate subtask and corresponding permissions security to specialize the agents, like like the freight agent, like the hotel agent, like the attraction ticket agent, and and and so on. This lead us to our third program. How do we decompose a single large task and is authorization into smaller subtask and permissions for multiple cooperating agents? The use case use case file is very similar to use case four. It also involves task decomposition here. The user is product manager. The manager states the intent, build a website for me. The main agent... AI agent requires the permissions for code access testing and development and deployment. It then delegates specific task and permissions to a specialized agent. We named developer agent and the testing agent. We know the developer agent need to get the code read and write access while the testing agent need to guess the permission to run test and also have the access to their logs. The signal reinforced the province we have already identified. The first is ensuring the... Like the translation from the intent building website to our specific technical permissions. And the second is effectively decomposing the task and its authorizations among different functions, agents. So let's quickly summarize the three Corey programs we have identified from this use case. The first is how do we ensure the accurate conversion of our users high level intent into a specific authorization request. This is a fundamental challenge in order five scenarios. And the problem too is how do we preserve their original intent and oscillization context when our task across different domains or different systems. And the the... Last the problem is in a multi agent system, how do we secure the composed complex task and is authorization for multiple sub agents. And we we we we would like to do the proposal. We would like to ask for for the working group adoption of the use case if if I think the use case can have... Can help us to make their gate and progress more clear in their... For it... Following solutions discussion. And then we also need suggested suggestion for the next steps. That's all. Thank you. And I I think I have saved five minutes.

[00:20:34] **Rifaat Shekh-Yusef**: Okay. Awesome. Thanks, Meiling. Anybody has any question, comments so far? Ankit?

[00:20:46] **Ankit Agarwal**: Hey, Meiling. Great presentation. I just wanted to clarify whether I understood correctly. Like, the authorization flows that you showed, in your workflow, are they deterministic, or are they probabilistic? I couldn't... I... Maybe I didn't catch that properly. So, like, does the agent decide or the LLM decide whether to get the authorization, or is it, like, deterministic by the human, or is it both? If you could kinda share your thoughts on that.

[00:21:20] **Meiling Chen**: Mhmm. Maybe you can, ask the details use case. Which use case you mean?

[00:21:31] **Ankit Agarwal**: Oh, I I I kinda meant it generally speaking. Like, so, like, if you have that fourth use case, as an example, if you go back to just say the last one where the, you know, the, I think the PM was creating a website or something. I don't know if you can go back to that one.

[00:21:47] **Michael Jones**: Okay.

[00:21:52] **Meiling Chen**: Yeah. This

[00:21:52] **Ankit Agarwal**: one. So is is the agent deciding that, oh, I should get an authorization request, which means, like, really the LLM is deciding whether to get it or not? Or is that, like, deterministic, meaning it's outside of the LLM? Like, the agent has to get the authorization and there's, like, guaranteed that authorization will be collected. Okay.

[00:22:20] **Meiling Chen**: This use case is from Peter, and maybe Peter can help to answer the question from Ankit.

[00:22:31] **Rifaat Shekh-Yusef**: Yeah. Go ahead, Peter. Thanks.

[00:22:33] **Peter Liu**: Thanks. If I may jump in. So I think the key factor here is the agent would do a little bit of the interpretation of the intent because I think the key message is here. The intent is intended to be somehow vague, but the agent itself will have to decide how would this intent or task will be interpreted as several specific authorization requests to specific resources. So so to answer your question, Ankit, this kind of information flow should be deterministic, but whether to request what kind of resource will be decided by the agent itself? Can I answer your question?

[00:23:26] **Ankit Agarwal**: Yes. Thank you, Peter.

[00:23:28] **Rifaat Shekh-Yusef**: But like, how is that deterministic, Like, these are agents that... We know agents are not deterministic. Right?

[00:23:38] **Peter Liu**: Well, they are not deterministic, but to... In order to finish... In order to complete this kind of intent or task, it will decide if it already have the sufficient access privileges or it will kind of need some more. So I think this is something maybe this... The presenter of today would suggest some kind of new work because to... Meaning, can we go back to the new use case number two? The use case number two is the one that involves payment and settlement. I think also Mike is gonna introduce this a little bit, but the the the the idea here is that the intent is actually provided by the purchase order of the original order or initiative that the that the user proposes. And this is the evidence of the initial intent using which the settlement service, like, the China UnionPay would be using this to verify if the following AI agent's payment request is reasonable. So I think this is, like, a two step process.

[00:25:00] **Rifaat Shekh-Yusef**: Okay. Hannes, you're in queue.

[00:25:05] **Hannes Tschofenig**: If you could go back to the to the others... To the other use case, the one... The more complex one.

[00:25:15] **Meiling Chen**: One... Use case one?

[00:25:17] **Hannes Tschofenig**: No. No. No. The the the one you showed before. And I think this was the... Not this one. Was

[00:25:25] **Rifaat Shekh-Yusef**: it for?

[00:25:27] **Hannes Tschofenig**: Yeah. This one. So I think the the issue here is when the agent comes up with the idea to, for example, to reach out to the flight agent, to the hotel agent, and and so on to some other agents to delegates the task. I don't think those those themselves would really require... Also, in most cases, I would expect that these agents don't require an authorization at this point in time. But, of course, when the flight agent... Like, it depends a little bit on what the protected resources are because those... These resources... Let's say, the flight agent contacts the airline and wants to get, for example, the the airlines have protected data about the flight schedules.

[00:26:27] **Flemming Andreasen**: Mhmm.

[00:26:27] **Hannes Tschofenig**: Let's make this up. And so then that flight agents would have to get the authorization and presumably Mhmm. The question is, does the flight agent then get... Reach out to the AES or is it the initial... Does it need to get back to the agent? Because it... That depends a little bit on the the relationships between the different parties here. I think that's that's the tricky part here. Whether that's the deterministic or probabilistic, I... The deterministic part is obviously asking the AES when there aren't sufficient authorization privileges available to make the request. The probabilistic part is, like, the agent itself to decide on how the whole plan works out and which resources to access. I think there are there are probably two components here. I don't I don't know if that makes any sense.

[00:27:33] **Meiling Chen**: Yeah. Thanks.

[00:27:37] **Rifaat Shekh-Yusef**: Okay. Thanks, Hannes. Okay. Let's let's stop here and give Mike a chance to present his use cases. And after that, we'll, we'll talk. Okay? Okay. Thanks, Meiling and Peter. Okay. Can you please stop sharing? Share slides here. Okay. I'll take control here. I'm gonna stop this. And, Mike, let me hand it. I think you have controls already. You know? Let me give it to you. There you go.

[00:28:25] **Michael Jones**: Yeah. I've got it. Thank you.

[00:28:27] **Hannes Tschofenig**: Yep.

[00:28:28] **Rifaat Shekh-Yusef**: Go for it.

[00:28:29] **Michael Jones**: Alright. Thank you all for being here. It looks like a good group. I know about two thirds of you, but I'm glad to see there's people I don't know. And thank you chairs for giving me the opportunity to present about this. So with Ankit Agarwal who was just asking the question about determinism, We've been working with partners building out a system called KYA pay, so know your agent as well as payment. And, you know, per the chair's instructions, I'm not here to talk about the solution or the solutions that we've developed but having developed the solutions with partners has taught us a lot about what is missing in terms of the standards to enable agentic commerce. So here we go. So the goal of the system we've been building, KYAPay, is enabling agentic commerce on the existing web and existing APIs and doing so in a way that is straightforward for people to incrementally adopt, that they don't have to rearchitect their whole system. So one of the core things that's necessary is enabling parties to decide whether to grant access to particular agents and part of that authorization decision is based on who the principal is that's authorizing the actions of the agent, who the human is. And done right, this can eliminate all the are you human captcha tests that otherwise the agents would face which would by design, reject most of the agents. Also, one of the features that we believe is necessary for this to really take off is enabling the use of websites and APIs without a preconfiguration step. And I'll talk more about that in a moment, but you would dynamically create any accounts or relationships as they're needed. And of course, if this is going to be ubiquitous, standards are absolutely essential so that people can build to an open system which is why we're here. So in summary, the rest of the presentation we're gonna talk about what do we believe the additions and gaps are to OAuth and indeed to Internet protocols needed to achieve the agentic commerce goals. So here we go, gaps. The first gap is our protocols are not currently carrying information about the human being or the organization authorizing the actions of the agent. I mean, we've been talking with people across the industry including at the w three c and other places, the OpenID Foundation. And this is a pretty ubiquitously understood gap. If you know who the person is, then you can either use an account that they have or use one that you create for them, for instance, when doing commerce. This information is used by all kinds of parties throughout the process. So content distribution networks like Akamai, fraud managers would look at this information like Ford and Mastercard, bot managers, Akamai f-five, etcetera, Datadome, account takeover managers, and CIAMs like Okta and Ori, all can look at this information and use it to inform gono go decisions about particular requests. And this can be used both by existing websites and by web APIs to authorize agentic access. The goal is to give your agent the same access that you would have as a human. And as I already said, this eliminates the need for the are you a human being tests. Next gap, also an identity gap, conveying the identity of the agent that is acting for the human principle or the organizational principle. It's needed to authorize access by the agent and it enables participants in the protocol flows to distinguish between agents. So you might decide to let certain classes of agents in and not let others. You might have detected that a particular agent is behaving badly and you can then block that agent without blocking all agents or all classes of agents. Now, there's been a lot of discussion in the I. T. F. And other places about let's reuse things that we can and we completely agree. I'm not here to reinvent wheels that already exist. You know, what is the identifier you use to label an agent? Well, there's already a bunch of candidates out there. Some of them in production use. So there's the SIMD URLs, which Arnaud and Arnaud have worked on and others. There's the SPIFFE URIs. There's others. You could put these in a claim and use them in a particular context. But if you have a token to authorize these things, we do have to define a claim in which to carry the identifiers in the first place. And furthermore, going back to the previous gap, these identifiers need to actually be bound to the human principle's identity as well. As detail, it's useful to represent both the agent platform or the class of the agent, the agent issuer, if you will, and the agent instance, the particular instantiation of that agent platform. So what does this enable? Then in these protocol flows, we can distinguish between humans, which are already populating the web, humans via agents, which is the new class we're trying to enable, and bots, which there's already lots of code out there to deal with them, sometimes not in an accepting way. Next gap. We think it's critical for agentic commerce to be ubiquitously usable that no setup should be required between the person and the site that you're eventually transacting with, such as a merchant. This may seem obvious, but if an agent can only use sites that have a preexisting relationship with the users, say the user has an account, a whole bunch of the value of using an agent would be lost. So the gap is the agent must carry sufficient information about the human and itself for the previous two gaps to be able to use sites and APIs previously unknown to the user without the user having to interrupt the flow and set up an account. Next gap for agentic commerce. Well, for commerce, you have to be able to pay. Again, this is obvious stuff but it's worth writing down because we don't have interoperable solutions to this yet. We need to enable agents to complete transactions on behalf of their principals. The payment information ends up being populated by payment providers unsurprisingly, the likes of Mastercard and others in the space and consumed by merchants. Again, there need to be data structures for that. There's privacy characteristics which are important which I'm not gonna take the time to get into about what kind of credentials you entrust an agent with or not. Finally, there's a set of three fairly specific gaps that have been identified by partners really deploying things such as Experian. I helped write the authentication methods RFC almost ten year... Nine and a half years ago now. And it turns out, revisiting that, we've actually made a lot of progress in authentication in the last nine and a half years. There's no authentication method reference values, for instance, to represent pass keys, authenticator apps, the use of these ubiquitous annoying six digit codes over various channels, facial recognition with a liveness check, and a bunch of others. This information would be provided to the parties in the interactions again for part of their authorization criteria. So that would be an extension to a spec we already have. Like that, there's no claim just listing, well, these are the identity verification methods that were used. How did you verify the person? And again, Experian and others really in the space need this to make authorization decisions about the person. And then in payment, it turns out there's these pesky regulations about anti money laundering and countering the financing of terrorism, which are American regulations. There's similar regulations around the world. But you need to make assertions to some of the parties that you have used particular anti money laundering methods, and there's not a claim for that. That's a gap. And then wrapping it all up, there need to be standard means of representing and conveying the information filling these gaps. It requires commonly understood data structures, giving the data for enabling authorization decisions for agentic access and agentic payment. And we completely believe that standards are the way to achieve this, which is why we're here. And you not only need the representations in the data structures, you also need sometimes protocol elements for communicating those things. Now, unsurprisingly, because we've really been deploying, there's a set of specs that do fill each of these gaps. We're not talking about solutions today but I wanted this to be in the deck so that those of you who are interested in solutions can go look at them. And the appendix in the first one has links to all the rest of them as an easy way to get there. So this is my last official slide. Our ask is collaboration on filling these gaps and solving these use cases, making agented commerce available to all parties that will require standards. And the Oauth working group is a place that is chartered to do that and I think is well positioned to help people succeed at that. Indeed, OAuth is going to be used for many of these flows, which doesn't surprise any of you, not just core OAuth, but token exchange, etcetera. And many of you are involved in that already, which is great. So I've got three backup slides about the solution. I'm only gonna touch on one and then stop. You can go read them yourself. But this is just too funny to not say. So at the catalyst buff, which was about agent protocols getting to have their day in the sun, our friend Eric asked nearly all the presenters this question. And here's my Ecker impersonation. Do you have a bunch of people who wanna interoperably use your thing, in which case you need a standard? Or are you just presenting your project, in which case, why are you here? And, you know, a lot of the presenters at the buff were not really ready for the question, but it's one of the right questions. And I will say that part of why I'm even working on the KYAPay solution is we do have a bunch of people building it and deploying it. With that, I will take questions.

[00:44:54] **Rifaat Shekh-Yusef**: Thanks, Mike. Okay. Any questions, comments? Hannes?

[00:45:06] **Hannes Tschofenig**: Mike, you... On one of the earlier slides, you talked about information about the user, which comes through the authentication of the user, the resource owner at the authorization server. I think it was one of the the slides. And clearly, that to a certain extent exists. Right? Like, if I think just about the information that ends up in in the access token, ID token, all the claims that we have, Could you elaborate a little bit more on whether you are thinking about that type of interaction or you are thinking about something entirely different?

[00:45:54] **Michael Jones**: It is certainly the case that there are data structures that exist in OpenID Connect and to some extent in OAuth access tokens that do carry information about the person. I mean, the issuer subject value, email addresses, sometimes there's other claims. And again, I'm not trying to reinvent the wheel. I already helped invent some of those wheels. That said, we're gonna have to have agreement on which of these claims we carry in which contexts in which ways, including potentially in these k y a pay tokens that flow through the interaction. To enable all the different parties and you look at all these parties in the chain in the sub bullet list and all of them are making decisions on your behalf. I mean, the web is not a simple end to end interaction. There's all kinds of parties in between. And each of them may make a go no go decision and they have to know what to look at and where to look for it. And again, we will reuse and are reusing things that exist but we're gonna need industry agreement on which of these claims to provide and how. Good question.... Clarification, Mike.

[00:47:36] **Rifaat Shekh-Yusef**: Yeah. Okay. Thanks. Flemming?

[00:47:43] **Flemming Andreasen**: Yeah. Thank you. So I I had a comment that was somewhat similar, I think, to what Hannes was saying, which is when I look at several of these, I think some of them are more along the lines of requirements actually because there are existing solutions for some of these things. Now you might be right that there might be a multitude of solutions, and, ideally, we wanna agree on a single one of those because that's how we get on interoperability. But I do think it would be helpful to take a step back and say, well, this is the actual set of requirements that we have. And then there can be a follow on activity saying, okay. Here are solutions that can satisfy those requirements. In some cases, there are no existing solutions, but I think that that would be helpful.

[00:48:24] **Rifaat Shekh-Yusef**: Okay. Thanks a lot. Good idea, Mike. You wanna...

[00:48:27] **Michael Jones**: Yeah. Completely agreed. And again, I applaud the chairs. I think this is a useful exercise to differentiate between gaps and requirements, which, Flemming, I believe you were talking about. Yep. And then reasoning together as a community about how to fill those. And, you know, preview of coming attractions, Ankit and I will be in San Francisco at IETf-one twenty seven where we'd be glad to talk with you about possibilities of solutions, but as much listening as talking. Alright. Thanks. Thank you.

[00:49:19] **Hannes Tschofenig**: Yeah. Mike brought up a very good point, namely, one, the reason why we thought it would be useful to talk about requirements and also these... The gaps that we have in existing protocols is because we've obviously been flooded with different requests. And so we somehow need to figure out on whether the requirements or the the gaps that people or companies identify and and also present today are ones that other others see as well. Because, obviously, like, if... Like, Mike, you just flashed up Ecker's remark on the screen. I think it's very appropriate because it's it's one thing if one company needs something. But, of course, if if multiple companies also see or or individuals see the need, then I think we are onto something. If we just outright standardize everything that shows up on our plate, then we probably would be busy the next hundred years.

[00:50:24] **Rifaat Shekh-Yusef**: Yeah. Okay. So so this actually leads to a question about how we're gonna proceed from here. And so so there is a one document from Meiling and team about use cases and and and gaps. And now, Mike, you have a a number of use cases and gaps. So, like, do we do we need more people to collaborate on one document and and kind of create a document that all of us agree on before kind of proceeding to the solutions? Or like... Or may... Or, maybe I'll ask you ask you differently, Mike. Did did you look at meetings document and see if you... If your use cases are covered there, or should should that being has to include other use cases and all... Like, what's what's your thought there?

[00:51:24] **Michael Jones**: I I certainly read an earlier version of it. I haven't read the the current version.

[00:51:33] **Rifaat Shekh-Yusef**: K.

[00:51:33] **Michael Jones**: But it... It's a fair question which

[00:51:37] **Rifaat Shekh-Yusef**: of

[00:51:37] **Michael Jones**: the gaps and use cases that we identified are in that document. If you would like, I would be willing to do that analysis and come back, for instance, at-ietf-ietf- in San Francisco would be great.

[00:51:59] **Rifaat Shekh-Yusef**: Yeah. It would be because we we need to make a decision on where we wanna capture those use cases, requirements, gaps, all of this, and make sure different people have different use cases will be captured.

[00:52:18] **Michael Jones**: Yep. I agree with doing the use cases work. That said, I think we should also consider solution work in parallel with that so that we're not Right. Delaying the industry. Yep. And I put this slide up which hints at a particular solution of filling gaps in the AMR claim. I mean, this is the most trivial but most, in some ways, obvious of the things that we talked about. We have a spec that is being reviewed. In fact, reviews of it were responded to last night by Max that, you know, we can define new values to represent how authentication actually works. Do we need that to wait until we're done with the use case analysis? I sure hope not.

[00:53:28] **Rifaat Shekh-Yusef**: Yeah. I I agree, Michael. I'm not suggesting, hey. Stop everything and and just focus on the use cases and and do nothing else. Right? That's not what I'm suggesting.

[00:53:39] **Michael Jones**: Yeah. I didn't think so, but I wanted to be clear on how I view that.

[00:53:43] **Rifaat Shekh-Yusef**: And I agree. But but we need to kind of nail down those use cases, gaps, requirements to make sure we are, all of us, talking about the same thing. Right? Otherwise, it would be a chaos. Right? Like, it's it's it's not gonna be pretty if we don't do that. Right? So...

[00:54:03] **Michael Jones**: Yeah. To the extent that we can minimize the chaos, we're all better off. I think k. We'll be surrounded by it regardless.

[00:54:12] **Rifaat Shekh-Yusef**: Okay. Then you have then an assignment to kind of look at that that document, and then let's

[00:54:18] **Michael Jones**: talk Perfect.

[00:54:20] **Rifaat Shekh-Yusef**: And we'll talk about it in San Francisco and then make a decision on how we wanna proceed from there. Okay?

[00:54:27] **Michael Jones**: Yeah. I I appreciate the work that Meiling and Peter and others have already done on that.

[00:54:33] **Rifaat Shekh-Yusef**: Yeah. Perfect. Okay. Hannes, you're in the queue or is that... Yeah.

[00:54:39] **Hannes Tschofenig**: Yeah. Go ahead. I I think, just to follow-up on this. I think, for example, the slide that we see on the screen, I think that's a very... I I like the way how you frame it because you have a very specific issue that we can sort of, like, clearly identify. Everyone in in the call can say, like, okay. Is this something we want to address? I... For myself, although I'm not deploying any of these technologies. Like, I can clearly see the value of registering these these IANA registry settings for, like, PAS keys and other other things. On some of the other... So we have a bunch of those, and I think it would be obviously very good since we have about 30 people on the call to get feedback on each of those issues to see whether we... Where we are and whether people agree with those. Also, for example, what Meiling and Peter talked about, the mapping of the intent to the authorization request. Does the authorization server need to know more about the intent to make a decision? How do we actually get that? I think those are very important questions in the AI agent context, and and we want to hear from others on whether they have the same problem or if they just... Mhmm. Yeah. Don't know.

[00:56:04] **Michael Jones**: And I look forward to what Karl's gonna say about this a week from now.

[00:56:09] **Hannes Tschofenig**: Yep.

[00:56:10] **Michael Jones**: Because he's thinking hard about that problem and making concrete proposals.

[00:56:15] **Rifaat Shekh-Yusef**: Yes. Yeah. That's next.

[00:56:18] **Michael Jones**: Yeah. To the extent that anybody wants to review the solutions underlying our thinking, they're on slide 12 of the deck. Okay.

[00:56:33] **Rifaat Shekh-Yusef**: Okay. Perfect. Thanks, Hannes. Okay. Anybody else has any questions, comments? Yep. Alrighty. So

[00:56:49] **Michael Jones**: Hi, Jen.

[00:56:49] **Deb Cooley**: Hi. Hi. I was debating about whether I come to the mic or not. Just remember that you have more options available to you than just writing Internet drops. Some of this that you're talking about is they're fluid, like, is probably the way I would phrase it. And so maybe it... There's a better... Venue is the wrong word for it, but, media maybe is the right word for it to to document this at least in the short term so that you don't get wrapped around the axle of, like, having to update IDs like every whipsnitch.

[00:57:31] **Rifaat Shekh-Yusef**: So so... Yeah. I... Look. If I understood what you're saying, Deb, you're you're you're saying for... From a requirements perspective, from use cases and gaps, because this is fluid and would change, We don't really need to adopt a draft per se. Right. And and this is... We've done that in the past. Like, maybe not the Oauth work group, but other work groups and and and maybe even Oauth. So so we... We've worked on on a draft, but the intent was not to adopt it as a official kind of work document and... Or or maybe... Yeah. But not not to publish it as an RFC, but just to capture those use cases. Is that is that what you're suggesting?

[00:58:16] **Deb Cooley**: That that is. And it's, like, there are other ways to do it. Like, Oauth could have a Wiki page, for example Mhmm. Within the IETF that you could that you could use for this purpose, and there you wouldn't be bound by the the ID, you know, rules and structure and all the rest of that, and it could be a little more free flowing. Yeah. The question is how long do you want it to live? The advantage of an Internet draft is it lives forever even though it's not good forever, but it does... Technically, it exists forever even though it's expired. Yep. Yep. Just... I encourage you to use what you think is the most flexible means to document this so that it doesn't take you four years. So I do think you need to be, you need to work at pace on this so that you can figure out the way Oauth wants to progress this. Efe Kahraman's questions are very good questions. He asks this all the time, by the way. You know, what's the interoperability concern? The only reason you need a standard is because you wanna interoperate with somebody. If you don't have an interoperability concern, then you don't need a...

[00:59:24] **Rifaat Shekh-Yusef**: Yep.

[00:59:25] **Michael Jones**: Right. The why are you here? To to get this point about methods, the intermediate point is what, for instance, Spice did for their use cases draft. They did adopt it and it's a working group document, but they explicitly said they never planned to do working group last call and progress it beyond being a draft. Then the working group does work on it and adds things and it lives forever as much as any of this will. Yeah. And that's what I think we could do is we could consider adopting Meiling and Peter's and coauthors draft and contributing to it. But I'm getting ahead of myself. That's for the chairs to decide.

[01:00:18] **Rifaat Shekh-Yusef**: Yeah. We'll we'll we'll cross that bridge when we get there. But we we can discuss it. We can go either way. It doesn't matter. It's...

[01:00:28] **Deb Cooley**: You will choose. I just encourage you to be flexible and not not... And to consider all of your options, not just only one of your options.

[01:00:37] **Rifaat Shekh-Yusef**: Yeah. Okay. Thanks, Deb. That's a good good suggestion. Hannes, you have more comments?

[01:00:44] **Hannes Tschofenig**: Yeah. I was hoping I was hoping that we could identify some of the things we care about most and then attach the solution straight to it and work on it as a as a working group document. That would that would... For me, that would be ideal because I understand, like, there's value in maintaining working group documents that describe just the use cases, but I I I want to get to the solutions at... As ASAP because the the whole industry is evolving quickly, so if we could work this out, what we care about most, that would be fantastic.

[01:01:24] **Rifaat Shekh-Yusef**: Yeah. And I agree, Hannes. And and hopefully, San Francisco is not far. So... Or in in a few more weeks, so we we will hopefully have a a clearer picture on on how we wanna proceed with the requirements and then kind of switch gears and start talking about solutions. And even in San Francisco San Francisco, we'll be talking about some solutions already. Right? So... Okay. I think we've passed the time here. Thank you all. That was a great presentation, good discussion. Thank you, Mike. Thank Meiling and Peter. And thank you all for participating. And don't forget, we have one more meeting next week on Monday. So talk to you then.

[01:02:12] **Michael Jones**: Thanks all.

[01:02:13] **Rifaat Shekh-Yusef**: Bye. See you

[01:02:14] **Hannes Tschofenig**: next week.

[01:02:15] **Meiling Chen**: Thanks all. Bye.

[01:02:17] **Hannes Tschofenig**: Bye. Thank you all.