Session Date/Time: 28 Sep 2026 17:00
[00:00:12] Rifaat Shekh-Yusef: Hello, everyone. We'll start in a few more minutes, maybe 01:05. Meanwhile, I am looking for unfortunately, Hannes is not gonna be here, so looking for a volunteer to take notes. Can somebody please take notes for us this time? Any volunteer?
[00:00:40] Bhavani Garikapati: I can take notes.
[00:00:43] Rifaat Shekh-Yusef: Thank you, Bhavani. Do do you know, like, we have that note tool at the that you can use? Do you know how to use that? You good?
[00:00:54] Bhavani Garikapati: I just opened it. This is my first time, but yeah.
[00:00:57] Rifaat Shekh-Yusef: Okay. Thank you. It. Yeah. We'll keep going in a few minutes. Okay. Let's let's get going. So thank you all for joining. First, Hannes, unfortunately, is not gonna be able to join. He's he's apologizing that he has conflict. Second, I wanna thank Bhavani for taking notes. Hopefully I did not butcher your name. Correct me if I'm
[00:05:39] Omri Gazitt: It's good. You're good?
[00:05:40] Rifaat Shekh-Yusef: Okay. Thank you, man. Appreciate it. And and let's get going. So the not well applies here. And for I I see lots of new people here. So for people not not familiar with this, not well is what is how the IDF conducts defines how the IDF conducts its business. This talks about expected behavior, professional behavior, civil discussion, IPRs, many other things. So if you're not familiar with this, please make sure to kind of take a look at the note well and get familiar with this. So we had two interims and today's interim is to talk about Anthropic and OpenAI agentic use cases. We have allocated an hour and a half for this, so we have plenty of time. And so we'll see how it goes. We don't have to use the full an hour and a half if we don't need to, but we have enough time, I think, for full discussion today. We still have two other meetings, one in October 5 and the nineteenth. We were thinking about another one in the twenty sixth, and we're not going to get that scheduled, so we'll defer it to San Francisco. So that's our agenda. That's our plan. Any comments, questions about this? If not, I'm going to stop sharing and get those slides. So who's gonna start the discussion today? Is it Paul? Is it Nick?
[00:07:41] Dick Hardt: Nick? Oh, there's Paul.
[00:07:44] Nick Steele: K. So Paul's gonna kick us off in a moment.
[00:07:47] Rifaat Shekh-Yusef: Okay. I will give you control, Paul. K?
[00:07:50] Paul Carleton: Great. Thank you. Yeah. So welcome. You all can you hear me okay?
[00:07:56] Rifaat Shekh-Yusef: Yes. We can hear you clearly. Yeah.
[00:07:59] Paul Carleton: Okay. So, yeah, here's some slides that Nick and I put together around OAuth and the sort of agentic use cases we're seeing that in Anthropic and OpenAI. So first, who are we? Nick, I'll go let you introduce yourself.
[00:08:15] Nick Steele: Sure. Hey, folks. I'm I'm Nick Steele. I'm a member of technical staff over at OpenAI. More specifically, I work on agent security and identity. So work on internal identity things and then also external identity things like this.
[00:08:29] Paul Carleton: Yeah. I'm Paul Carleton, a member of technical staff at Anthropic. I work on the Model Context Protocol and authorization at Anthropic. So oh, my my handshake emoji is missing, but this is supposed to be OAuth and and and LLMs with a good handshake. So but why bother listening? Like, why do we have a session here? I think, you know, LLMs and OAuth go super well together. The agentic LLM applications make a lot of OAuth connections. And when those when, just off between things, standardized, it makes those connections, simpler and simpler to secure. So that's kinda why why we even, maybe think this is this is all in here. Oh, yeah. Nick, did you wanna talk about this one next?
[00:09:28] Nick Steele: Oh, yeah. For sure. So, this the the problem sets that we're gonna cover in here, we're gonna cover, like, three main topics are are kind of the the problems that we have seen in practice. This is not, like, more of it is this is less theoretical, more deploy I'd say applied. So I think we've Paul and I have, like, both seen these issues, like, firsthand in in deployments and in our own configuration. So trying to get a better just a view of of, like, the the the problem space as it exists in, like, in in actual application of that. Next slide. So we can we can talk about solutions as well on these slides, you know, are are are gonna define the the problem spaces, and we'll talk about how we how we see see these, deployed and fine. But, also, yeah, feel feel free to ask questions about the problems and and what cases are are occurring. And and, you know, we're more than happy to talk about some candidate solutions, and I I hope to that those solutions get raised in in our discussion. And we'll also book in these sections with or with with time to discuss and and take questions on on each. So, yeah, in terms of pick picking solutions and arriving at a conclusion that's kind of out of scope for this. Alright. Take it away, Paul.
[00:11:00] Paul Carleton: Cool. And so, how we we're breaking it down as as Nick and I were talking about this were these sort of three areas, and we'll try to go, dive into them one at a time and then have a little discussion break in between. And so the three problems are sort of boring OAuth problems. This is using OAuth in a, fairly typical way, but the problems that surface when you're trying to do it, with LLMs. And then some more maybe LM specific or agentic things that that come up, which are around, principal selection. And then, the last one is around scope issues. So the issues with the current way we handle scopes in OAuth and, and what makes that difficult. Great. Okay. So the first one, the boring problems. These ones yeah. These are not aren't super agent specific. They're more they come up in the way that we are, using, OAuth in agents. So LLMs make very nice, general purpose OAuth clients because they can connect to applications they've never seen before and do useful things with them, that wasn't as true before with, with with applications. And so the number of connections that's reasonable to make from a single, LM application is way more than, than would have been reasonable before. And then as a result, also, like, you might have spent a month integrating a new resource into an application or or even longer. It's it'd be very,
[00:12:43] Dick Hardt: like, sort of
[00:12:45] Paul Carleton: labor intensive to do that. And so you would whereas now it's sort of it's more kind of plug and play, almost like a keyboard. You just wanna be able to plug things in and and they work. And so the expectation is that that things plug much more easily. So that that comes up in a couple ways. Any inter integration friction is really visible. So we see this in MCP around client registration, which we'll talk about in in the next slide. We also see this when the coordination between users, clients, and servers is is is slower. Like, the it becomes very apparent that that is slow. So this is around, like, you get an error as a user, you report it to the client, you report it to the server, and then they have to go dig into that. Whereas previously, if they had spent a bunch of time on that integration, it may have been better tested with all of that particular combo of user, client, and server. And then kinda related is that discovery we found is much more important since zero preconfiguration is is much more common. So there there are situations where preconfiguration exists, but there's also a lot more where it's expected to work without preconfiguration. Okay. So on the client registration side, here's the shift that that we're seeing where, previously, it would be a client developer that picks a, an application to integrate. They register that client. They test it. They fix it, and they, you know, repeat it until it works. And then they will ship it, with a client ID that they registered. By the time a user sees it, that's already you know, that combination has been tested. What's much more common now is the developer ships a general purpose client, as an agent harness or, some sort of tool like that. The user wants to be able to just plug in a server the client may has never may have never seen before. And then the client and server or client is supposed to basically expect discover the server, register. And then if the user gets any failures there, that it's it's not necessary that the developer knows knows what that server is, has a relationship with that server, or is is able to debug it easily. So one of the, ways that this has gotten better, on the MCP side is with client ID metadata documents that at least takes away some of the registration friction. So that's a, you know, a promising direction for that. One, sort of similar, theme that comes up is is how do I test if this is working in a in a client registration case where, ideally, you wouldn't need to have a working user account at the the downstream resource in order to test that that it's all connected. So even with CND, there are some, some challenges with testing that. Yep.
[00:16:02] Rifaat Shekh-Yusef: Got it. So sorry. Finish your thought first.
[00:16:08] Paul Carleton: Yeah. So sorry. The the last thing is just with even if TMD takes away some of the registration friction, if you use private key JWT with TMD, you still have a a a bit of a challenge there in determining whether that works without having a user account.
[00:16:26] Rifaat Shekh-Yusef: Yeah. There is a question in the chat there about what do you mean by server in this case. And and, guys, if you have a question, feel free to kind of join the queue and ask that question. But, but, yeah, the question in in the chat there. Go ahead, Pieter. You joined the queue.
[00:16:46] George Fletcher: Yeah. Oh, just I
[00:16:48] Pieter Kasselman: just wanted to clarify, Paul. When you say server on the previous slide, that was the authorization server that you were referring to. Correct?
[00:16:57] Paul Carleton: Yes. I wasn't really differentiating between resource and that would basically, like, the application. So the resource and the, app the authorization server. Okay. Thank you. Yep. Cool. Okay. Where were we? Oh, wait. I went too far ahead, didn't I? I went way too far ahead. Okay. Client registration. Yeah. Okay. Cool. So, yeah, we talked about this. Next issue we see is consent screens in OAuth. When you're making a ton more connections, you end up seeing a lot of consent screens, which then starts to raise the question of which, which ones of these are the most valuable, or, like, what what what is the user doing when they're doing a consent screen? Or what are they what are they consenting to? Should they be the ones consenting to it in that sort of enterprise situation? I know, Nick, you wanted to mention something too about about who presents the consent screen.
[00:17:57] Nick Steele: Oh, yeah. And the so the other the other issue we see with with consent too is is it it could be fairly decentralized. Right? Even even in flows, and I'll talk about this a bit more during the scope section. Right? But even even in flows where we have auto approve or there there's it always ask flows in in place and consent is occurring in the client, there's flows upstream that can can ask for additional consent, and we see that manifesting in different ways. Right? There's now, like, Cboe flows. There's MFA flows. There's authorization additional, like, authorization that might occur resource side. But right now, yeah, there's there there's not sort of a a a central way to from, you know, end to end to to have that that authorization proliferate and, like, be honored, rather it has to occur in different sections of of of this flow. Thanks. Yeah.
[00:18:53] Rifaat Shekh-Yusef: And, George, you have a question?
[00:18:56] George Fletcher: Yeah. I I guess I'm maybe I'm missing the consent problem. But if the LLM is working with 10 different applications and each of those applications is effectively issuing an access token for their application, right, whether that's somehow combined with the resource server or split, then each of those applications needs to know that that they're going to need their own sense of, yes, the user has agreed to connect these things. And so, Nick, I'm a little bit confused. Like, are you saying that somehow that should be predetermined? Like, as a user, I don't know that I wanna tell the LLM, anything I tell you to connect to, you've got free carte blanche to do whatever you want there. Right? Because some of those consent screens can have choices in them. Right? So, like, when I connect a financial institution via Oauth, I can tell it only these two accounts, not all of my accounts. And so I I don't know. I'm a little bit I'm just trying to, I guess, better understand, like, where the consent problem is. Because it seems like if I was the owner of one of those applications, I would want to know that my user explicitly agreed to share this stuff with that LLM.
[00:20:19] Nick Steele: Absolutely. But, I mean, let's let's talk let's talk about that that that type of flow and where we might see consent start. I asked my agent to go connect to to to the to a bit to the a bank of this financial resource. I get a request right right off the bat to allow the agent to do that in the client. I then get a request to authorize the agent to contact the bank. The agent then can, like, work with the bank and might be allowed to do a certain set of things, and then I get another request that allows it to complete for for it to complete whatever task it's it's trying to complete. And then I might have additional MFA steps in between. So I'm not saying that these don't need to be there by by any means. Like, we should have ways to to provide, you know, like, user authorization consent and, like, have have them in the loop and and allow for these, like, high assurance flows. But, like, how and and where we present them all, like, as as sort of, like, you know, a coherent cohesive, like, authorization might might be might be more helpful. That's what I'm getting at.
[00:21:25] Paul Carleton: Yeah. I would agree with that. Or sorry. George, do respond? Oh, maybe it was Donoket.
[00:21:35] Rifaat Shekh-Yusef: George, you have a follow-up? Or you still there from the
[00:21:40] George Fletcher: previous No. I was just sorry. I forgot to hit the unmute button. Okay. It just feels like one of those cases where we need to map it out in a lot more detail because there's a lot of potential for potentially bad privacy things to happen, right, in the goal of trying to remove consent screens. So somewhere in this process, we need to ensure that the right the user is able to control the things that they want and the applications get the data they want. And some of those other authorizations that you were talking about sounded almost less like user authorizations, but is the bank willing to allow this LLM to talk to it or not? I don't know that the user should be involved in that at all. So, anyway but thanks. We can keep going. Sorry.
[00:22:29] Rifaat Shekh-Yusef: Yeah. So Jonathan has a comment. Jonathan, do you wanna speak to that comment?
[00:22:36] Jonathan Rosenberg: Sure. It's it's a comment slash question, I guess. Along on to what what George just said, I mean, is the problem here that there's just so many consent screens that we're gonna users are just gonna get trained to say, you know, as we already have today with Claude. Yes. Yes. Yes. Yes. Yes.
[00:22:50] Nick Steele: You know
[00:22:50] Paul Carleton: what mean? Exactly.
[00:22:51] Jonathan Rosenberg: And bad things happen. So that and the and the and what's new is that there's just more of them because the AI agent can connect to so many things so easily and do so much more. We have it that's that's worse than it was previously. Is that what you're sort of saying?
[00:23:05] Paul Carleton: Yeah. I think that I think that's part of it. Or I think sorry. Nick, did you wanna talk about that placement of it? Or Oh, no.
[00:23:10] Bhavani Garikapati: No. I yeah. I think I
[00:23:11] Nick Steele: think it's more about the the where where consent needs needs to lie and the sort of, like, having a a central source of, like, where where that can where that consent needs to be needs to take place, this that that ceremony. And, you know, maybe the solution is like, yeah. Okay. Once it once it contacts the bank, you know, maybe we we can on the on on the harness client side can say, like, okay. Let's assume it's like to contact the bank. At that point, the agent can appear and the bank can set up and say, this agent is trying to create a request on your behalf behalf. Like and then we we begin consent on the resource side rather than, like, perforate it and carry it through. Like, it it manage it so much through the client. Jonathan I mean, to to Jonathan's point, you are correct. I do think there's a certain amount of push fatigue associated with this where users can, you know, to reduce reduce their own friction, just, you know, hit confirm confirm. Yes. Yes. Yes. But it's also about, like, how we can move this into into a boundary where where where the resource is able to res receive the consent it needs and the context to make good decisions there. So it's less about, like, re reducing the the power of a consent or or or, like, authorization, but rather, like, figuring out how we can make those consents more meaningful and stronger at the resource that's being accessed rather than downstream on the client on an authorization server or, like, on like, the the steps before it rather than having the resource be sort of, like, the the, decider and enforcer, in especially in these consumer flows.
[00:24:57] Rifaat Shekh-Yusef: Okay. Thanks. Ankit?
[00:25:03] Ankit Agarwal: Just along the similar lines, I just wanted to also ask how you guys think about, like, in these agentic flows, like, you know, like, having actually many more consent points just given that it's an agent. So maybe you don't give, like, long lived permissions. Maybe it's a permission just for that task or just for a very short time, and then there's many, many more of those. So just going back to what you were saying, Nick, about how do you kinda manage that proliferation. But I I also see, like, potentially many like, much more than in the human world. Many more, yeah, occurrences of that.
[00:25:48] Paul Carleton: I think it might be better so we have a whole third section that's about scopes being too broad, which I think it starts to get into there. Where I think that this one's more about, like, if you do want the normal a lot scope thing, we are hitting a lot of consent screens. To Jonathan's point, you are getting consent fatigue in a way similar to the way you get to approval, fatigue in, in in the CLI tools today. Cool.
[00:26:18] Rifaat Shekh-Yusef: So, Bhavani, you have a question or comment? I see you off mute.
[00:26:24] Bhavani Garikapati: No. No. I don't have any. Sorry.
[00:26:27] Rifaat Shekh-Yusef: Okay. No worries. Okay. Keep going, guys.
[00:26:32] Paul Carleton: Cool. Yeah. So, consent fatigue, and then another one that's similar on the consent screen category is this cross organization, consent problem where you are have started a, an off flow on your corporate you know, you know, from your your your work account, and then you either by mistake or because you're, you know, being you you've connected to to your personal account, now you have, you know, company data flowing to your personal or vice versa. You actually have your personal account you've connected to your corporate, which is, kinda difficult to to solve today. The and then the the current work there, I think ID4iag helps a lot with this on both the, the consent screen. There being too many consent screens and on on the corporate personal crosstalk issue. The way it helps for us on the consent screens is that for ones where it is, you know, a default read scope, if the if it's actually the IT admin being the one approving that, then you the user gets to, you know, not like, what will happen today in the in the enterprise environment is you get prompted with the consent screen, and it's not clear how much you scrutiny you should apply to it. Because it's like, if my company has already approved connecting this tool, do I need to be really paying super close attention to this, or is this fine? There is the case of, like, do I actually want this tool to be able to connect to that, which is, you know, kind of a separate personal preference thing. But, you know, do I need to be, like, applying search to security scrutiny to this thing? Because I think where where ID4iag helps a lot, today, but that's kinda, like, the shape shape of problem that that we see a lot. Yeah. Kahraman?
[00:28:24] Efe Kahraman: Yeah. Hey. Sorry. Hey. Hey, Paul. So I was just curious whether or not either of you guys have taken a look at the deferred token response draft as a potential for something that can sort of act as a as a way to, like, help with the with the consent fatigue, you know, with the understanding that the that the agent would receive some sort of consistency token. And on the and on the back end, driven by some sort of policy on the AS or somewhere behind that, you know, the principal can either provide, you know, a broad based consent or, you know, issue issue that consent as on an as needed basis.
[00:29:08] Paul Carleton: Yeah. I think that is super useful. I probably should've listed that here as as another another area of work that I think is super interesting here too. Yeah. Yep. Yeah. I think this is, yeah, helpful for the solve this help help with this problem.
[00:29:21] Efe Kahraman: Okay. So it's definitely, like, something that is that is on your mind. It's not completely out of left field.
[00:29:26] Bhavani Garikapati: Yeah. For sure. Okay. Thanks.
[00:29:31] Paul Carleton: Cool. Okay. So consent screens. What do we got? Oh, okay. Next page. The next tricky one is around refresh tokens. We see this this amount where it's just, often we want a refresh token. We didn't get one. It's a little bit difficult to tell why you didn't get one and then also hard to remediate. So this we have the offline access scope in OIDC, which is somewhat useful, and then we have the grant types supported in metadata. But when you don't get one, it's difficult to tell whether that's because your particular client is not trusted with a refresh token for some reason that you would then remediate or whether the server doesn't grant refresh tokens ever, or if it was expecting some scope or other, other option in order to get a a refresh token. So this is just a sort of a annoying problem you see when you're trying to connect to, like, a a whole bunch of of lost servers. Cool. And then we've got, yeah, leaked tokens. So access tokens are generally, bearer tokens. So when those gets leaked, usually, the one that I, get get bugged about most is around they get logged somewhere, and then you have to sort of very much be concerned about rotating those secrets and and and validating them, especially if they're they're long lived access tokens or or refresh tokens. Ideally, they would be less long lived, and we'd have less to worry about there. There's a whole bunch of different, approaches, but this is just, a general problem that, we would love, to to get better in in the ecosystem, both with, like, adoption of of more things and and some more feature work. So under constraining is one thing that would help. Shorter lived tokens, no refresh tokens would help, with the where ID4iag and and workload identity things, help with that as well. Cool. Okay. So I think we already had a bunch of discussion, but, in case, I'll I'll have a little pause here of, if folks wanna flag things on that that first section.
[00:31:54] Bhavani Garikapati: Filip? Yeah.
[00:31:57] Filip Skokan: Just one one one question on CIMD-doc. I'm I'm a huge fan of CIMD-doc in this space, but we also deal with clients that are not able to host CIMD-doc files. Like, there are local clients that are running an environment that can't host these files. What what do you propose here? Because I know MCP also support DCR, but it is deprecated in the documentation, which I found an interesting decision. So I I wonder what your thoughts were on that.
[00:32:24] Paul Carleton: Yeah. That's a it's a tricky one. For local host, what we do for, like, Cloud Code, for example, is you just have you host the CIMD-doc on a remote server and then have the redirect to be local host still. I've put a blog post on the model context protocol blog about the sort of threat matrix where I think that's actually still a better situation than than like, the the the threats you have to worry about is, like, compromise on a like, in order for it to hijack a local host redirect, you have to be fairly compromised locally. So it's a slightly different threat situation than if you have your your redirect URL be HTTPS. So it's not a a great solution, but that's that's the the best we've got so far.
[00:33:17] Filip Skokan: Okay. Thank you.
[00:33:23] Paul Carleton: Cool. Okay. Let's keep rolling. Alright. The next challenge, this one's a little bit more, I guess, agentic or, LM specific. Sorry. This one's got a lot of text. But the there's this, a lot of different ways you can sort of slice and dice who is the subject, in, like, the JWT claim case and who is the in the, token exchange has this actor claims that, and, like, what which to put what, where where to put what, in those, setups. And I I think we have the kind of the conceptual framework to be able to fit these couple different use cases in there, which I'll go through. But whether they're actually used in practice or whether whether there's actually, like, a lot of guidance around how to do this, I think it's a little little low. So you have, the where the like, the normal case I'll just run through these, and then I'll I'll I'll, get the questions so I don't lose a train of thought. But the, the first one is the simplest where it's, like, sub as the user, and there's no act claim. This is just plain. Don't get it off. That one's pretty simple. Second one is if you wanna use the user's permission, but the, agent is the in the act claim. This is more like the, this one gets a little bit conflicted on whether you wanna do the act as the agent or head of the client's fee. You know, the agent application, a little bit, tricky there. And then on the, if the the if it's more like a service account or agent acting on its own case, then you have the sub as the agent. And if you have the user who initiated that particular conversation turn, that one works. And then the last one, if you have sub, you this agent with no act claim where it's sort of on a, you know, fully autonomous, cron job, something like that. That's the the fourth one. So I feel like we have the vocabulary for this with sub and act, but there isn't a whole bunch of adoption of using it that way or or a clarification.
[00:35:35] Rifaat Shekh-Yusef: Dick?
[00:35:38] Dick Hardt: Curious, Paul and Nick. You're sort of putting yourself, saying, here's the terms and how do they fit, but it might be be interesting to sort of take a step back and try to figure out why are you trying to con communicate in the call and in the token as opposed to trying to fit into existing claims that are there.
[00:36:04] Jonathan Rosenberg: Right?
[00:36:06] Paul Carleton: Yeah. Sorry. I I think what I'm what I'm trying to show here is four things we are trying to communicate and then what what claims we'd use in that case. That makes sense. So it's like, usually, it's like,
[00:36:17] Dick Hardt: there's always permissions. I mean, there's always gonna be an agent, right, by by definition of the problem we're solving. Right?
[00:36:27] Paul Carleton: So it yeah. There's there's always gonna be an agent whether it's in the act claim or whether it's, you know, a client ID is sufficient. That's
[00:36:33] Dick Hardt: Right. What I'm saying is you're saying whether it's in the act claim or in the sub claim, and I'm saying maybe those are the wrong claim names for what we're trying to communicate. Right? May maybe the Yeah.
[00:36:45] Paul Carleton: That's fair. I I may have gone straight to
[00:36:47] Dick Hardt: switch an agent claim, then it would be clear that the agent claim is always the agent. Right?
[00:36:53] Paul Carleton: Well, I think that there there is, like, this case. Right.
[00:36:57] Dick Hardt: How it breaks down as opposed to the solution, you're trying to saying, here's how we're solving it now. It'd be useful to step take a step back and try to figure out what signal are we trying to send around who the principal is because it's unique here because we're not we're trying to say the agent, and we're trying to say, at times, the the human. Right? In in a auth, we have the model of a person, which could be either an org or a human that's acting. Right? Because agents don't do things by themselves. And it clearly isn't just a person, and often the other end would like to know or something along the line would like to know that there's an agent involved somewhere
[00:37:37] Bhavani Garikapati: along the line.
[00:37:38] Nick Steele: I I I agree. I think that that that is that is a a more optimal approach. Then, again, the the, like, the what what we're what we're chatting about again today, right, is, what we're seeing in practice and we're seeing what we'd like being applied. And so these these are the the primitives that we have to work with. Like, today, when we're when we're using or when, you know, com companies are are implementing agents, they are using these these tools to try to accomplish getting getting this amount of authorization in place. So, absolutely, in the in the in the future, I think that there there there there could potentially be a a, you know, a better identifier or, you know, or or or value here for for for managing what what that agent is, who it's acting on behalf of, and we don't have to, like, necessarily tie directly to, like, subject actor here. But this this is what, we see being deployed.
[00:38:33] Dick Hardt: Oh, yeah. Yeah. But the the presentation was around you guys talking about what are the use cases you're trying to solve. So I'm interested in use cases as well, right, which is Sure.
[00:38:44] Ankit Agarwal: Yeah. I think And tied
[00:38:46] Dick Hardt: into this is also, like, you know, it seem that you might wanna know, like, which specific instance of agent as opposed to it was Claude that made the call.
[00:38:58] Paul Carleton: Yeah. Exactly. Yeah. We'll get in we have a slide on that one exactly later.
[00:39:02] Dick Hardt: Because that's I think the principle. Right? Yeah.
[00:39:05] Paul Carleton: The the yeah. The piece I'm trying to or, like, get at here is that sometimes you want it to be the user's permission that the agent gets, to sort of borrow for a second, or it's like if I own a doc, then the the agent can read that doc. And then sometimes you want it to be the agent's own permissions, and I'm just I'm the one instructing that agent that's that's doing it on its own.
[00:39:28] Jonathan Rosenberg: Right.
[00:39:29] Paul Carleton: And so, like, we we there is the sub and act claim as, like, a way to convey what's going on there. But even within that, there's not, a ton of, like, standard usage of that. Like, it's kind of internally folks can decide what they wanna do, but that's not, like, a a broad ecosystem thing.
[00:39:48] Dick Hardt: Okay. Thanks.
[00:39:52] Rifaat Shekh-Yusef: Okay. Thanks, Jeff. Sorry. Yeah. And, Dick. Jeff, go ahead.
[00:39:57] Jeff Lombardo: Yeah. Sorry. Very small tangential to that, and I did use cases onto that is the possibility. Like, the client ID may not be might not mean something end to end. So when we want, like, to correlate all the activities in between all those action and all of that, that's that's where I start to eat very hard because we need to correlate more and more and more things along all the operations. So so that's also a problem we saw we saw on the feed.
[00:40:27] Bhavani Garikapati: Yeah. Thanks, Jeff.
[00:40:32] Rifaat Shekh-Yusef: So, there are a few comments in the chat. Any do people wanna bring those to the mic here, or should we keep going? Okay. I don't see anybody joining the queue, so keep going, guys.
[00:40:52] Paul Carleton: Cool. Okay. So one is, one of the issue around clients and principles is is when you have a multi surface client. So we see this a lot. You know, Codex has several different services, clients, several different services. You want to have balance user consent with these things, but also not distract, if if the like, decide when that consent is transferable across surfaces and and what makes sense there, which gets kind of messy. And then I think this kinda gets back to what, maybe this is what what the an issue that that Dick and and and Jeff were talking about as well is is that we have this at what level do you want to convey different information and and and where do you do you wanna put it in the token or not? So we have, like, do you wanna create a whole new client? Do you wanna create a new new principal, or is this just metadata, like, additional claims that you're you're supplying? So some different models we put here is, like, it's the application publisher. That's, like, often, client ID is is is often in there. The surface is is it's in. So whether that's, you know, Claude.ai or Slack or or these other inbound services, whether it's a part of a particular project, that might have some permissions associated with it, if there's an individual ticket or task or objective. And then you might have a conversation. So, like, if you have it in a Slack thread and then an actual in an individual turn, of of a conversation. And so these are the different levels that you might want metadata on, and those could go in lots of different places in in the different, like, OAuth token exchanges and things. And we have with that a cardinality problem, which is kinda similar to what we saw with DCR where with DCR and MCP, we had this cardinality problem where we had these databases that were expected to have sort of low cardinality on client ID, explode with a ton of client IDs as they're dynamically registered. And so if we have a kind of sort of a cardinality mismatch on any of these where, you know, someone's expecting your clients to be at the cardinality of the, you know, application publisher, but you're actually sending, this information, every term, the sort of cardinality mismatches are are something where it feels like we need to to solve it in general.
[00:43:19] Rifaat Shekh-Yusef: K. John on phone.
[00:43:23] Jonathan Rosenberg: Yeah. I have a I have a question on the on the cardinality aspect. Is is the issue just the number of principles, or do you see a need or have you found problems where I even want the permissions and scopes to vary by these things? And I certainly can imagine that, like, I'm using Claude, and I have, like, a banking agent that I spend a lot of time configuring my guardrails and skills and whatever, and I trust that to do transfers for the general purpose, you know, other agent with a different harness configuration. Like, I don't want that one to do transfers. And so even though it's Claude under the hood and it's the same LLM, you actually have two different sets of permissions that I wanna grant as an end user controlling the system. Are is that what you're saying here, or or have I got this wrong?
[00:44:08] Paul Carleton: Yeah. I think it's a there's, like I think where you're hanging the permissions is on one of them, and then the other one one is, like, what is how is it represented in the downstream system as well? So, like, as a user, I might wanna be able to express something more fine grained like that, which I think we'll get get in more to in the scopes part too. But then as in, like, downstream system, what do I enter in my, you know, database of principles? Do I you know, should I be recording conversations, or should it be, you know, a project scope? Like, what is the most useful thing? It it all kind of, like, ties in together, so it's a bit a bit messy. But yeah.
[00:44:42] Nick Steele: Yeah. I I think that there's kind of, like, two components when we're talking about, you know, the the client the client here and then the context around it and the con and the format in which that takes and and sort of modifies its its its access. Right? There's the what is what is the identity of of of the agent the client is connecting with, and then what does that mean within the the context of what it's trying to to achieve? So having the you know, what the the the task and objective currently, right, is not, a strong modifier of what it's allowed to access. So being able to, like, store the principle is one thing, and then being able to act on it is could could be another. But, yeah, we'll talk about that in Skokan.
[00:45:23] Rifaat Shekh-Yusef: Okay. Mike?
[00:45:26] Michael Jones: Yeah. I wanted to say that in the k y a token solution that I've worked on, there's definitely different claims for the agent platform versus the agent instance. And we found that to be a useful distinction.
[00:45:52] Paul Carleton: Nice.
[00:45:52] Rifaat Shekh-Yusef: Yeah. Okay. Thanks, Mike. Ankit?
[00:45:58] Ankit Agarwal: Yeah. Actually, Mike had the same idea. But I I wanted to actually find out from Nick and Paul, like, know, one of the things we see missing here is, like, the agent instance itself. And, you know, to some extent, it could be correlated with the task or the objective. But then it could be longer lived as well, but not as long lived as the application or the surface itself. So, like, you know, Claude agents or something that come up and down, like, does that become another layer in this explosion of you know, in this cardinality explosion, really?
[00:46:36] Paul Carleton: Yeah. I mean, I think that's that's, like I think what you're highlighting is exactly the problem. It's like, if you have like, when you say a cloud based agent, which which layer on this existing set of bullets? Like, is it a longer lived project, or is it or are you for in on the, you know, agent or client side, which is it? And then what is the server expecting you to to represent? Like, what kind of cardinality are are they expecting Yep. Is the difficult part.
[00:47:04] Nick Steele: Yeah. There there has there hasn't been a lot of talk about how how deployment sort of affects the the management model. You know, we I I so when we had the other client slide up. Right? Like, there's there's different there's different deployments of of, you know, both both, like, open AI and product source. Like, some some are entirely in the cloud. Some are just using inference. Some are using a combination of inference and then also managed connections. Some use workload identity federation. Some don't, which, you know, implies that they might also have their own, you know, credential or key management solutions in place. But, like, depending on on on how the a lot of these deployments are structured oh, yeah. And and I you just heard Chase on on the line here to keep me honest. Depending depending on those might change how that principle is sort of sort of manifest and is, like, stored and orchestrated and logged.
[00:48:01] Bhavani Garikapati: Yeah. Okay. Dick.
[00:48:05] Dick Hardt: Yeah. I was inspired by Michael's comments in your use cases. You know, it would seem like you would also want to know more about the agent. Right? You guys have a wide variety of deployments. Right? You know, sometimes it's Claude, but sometimes you're just the inference endpoint and some other piece of code is calling. You know, what what are your thoughts on your requirements for knowing, you know, posture, verification of the agent? Like, is it really your software calling? Is it really the specific agent? Right? Moves more to just being an instance identifier to being, you know, more verification of what exactly is it that's calling.
[00:48:50] Paul Carleton: Yeah. I think that kinda gets into the the, like, surface it's in and this, like, multi surface thing of, like, is this you you may have set up this agent in one way, but you're calling it you know, I'm texting from my phone. Is that, do you wanna apply some more scrutiny there or or not? Is is that kinda what you're saying, Dick?
[00:49:11] Dick Hardt: No. Surface is a different dimension. Right? I'm on my phone, and then I would wanna know, like, the resource one might wanna know things about, like, where is that at and who's calling? Is it calling, you know, things as as much as is it in a control IP range, or is it mobile? Is it on the Wi Fi? Is it on, cellular? You know, is it really that particular you know, your software client? Right? Is it the, you know, Claude on a phone, or is it, you know, something else that's running on my machine? Right? So posture things, verification things of which software is it. You know, that whole stack that enterprises sometimes manage, you know, completely like, it's never been part of OWAP, but often now might be part of an authorization decision around do we wanna give access to this thing, given the power of agents? That's the that I'm
[00:50:19] Paul Carleton: I think I lost it towards the end of that. What the so the surface is one thing and then
[00:50:24] Dick Hardt: Well, surface could be just mobile or desktop or, you know, a a workload. Right? But diving deeper, it's like, okay. It's it's a workload, and it really is this binary, and it really has this posture of the of that. You know, it it's on a managed device in my enterprise. It isn't just calling from some other place.
[00:50:46] Jonathan Rosenberg: Right? Yeah. I guess I just
[00:50:47] Dick Hardt: wanna know posture of something and making that authorization decision.
[00:50:52] Paul Carleton: Sure. Sure. I I I think in my head, that's more like surface plus plus of, here is the surface that's coming from and, like, here is, you know, a lot more about it. But yeah. Yeah. I agree that's important.
[00:51:02] Nick Steele: Yeah. I it it is important. We can we can we we can discuss discuss this towards the end of the call over a beer in San Francisco. I have a lot of big feels about this. But the yeah. The the the surface, I think, a lot of time will be fairly opaque towards the surface towards the service con consuming, especially in, like, in consumer in consumer cases. In the enterprise, I'd expect a lot of the time that when the nation is instantiated, these will be used to make sort of, like, the initial, like, orchestration, prop provisioning, and and, like, allowance decisions. And then a like, some some sort of proof can can be presented that this is trustworthy by the person enterprise team that that that has stood it up. But a lot of the time, right, where it's like as especially for sort of, like, a first pass, we'd like to hit point where it's like the information that we are presenting, the scopes, permissions, the identity are consumable and enforceable by by the the resources that that have to consume it. And this is not entirely a unilateral decision that is made by the the the client and, you know, what a what whatever sort of, like, downstream gateway stand for before the resource, especially when when we're talking about lack of granularity. But, again, we'll get to scopes to talk about it
[00:52:16] Paul Carleton: more. Okay.
[00:52:18] Rifaat Shekh-Yusef: K. Thanks, Nick. Jessica?
[00:52:23] Jessica Trochet: Hi, y'all. For context, I operate identity and internal authorization for OpenAI. One of the things that's come up for us repeatedly, because of the lack of an overall high cardinality client primitive in the environment, is that we repeatedly find ourselves using relatively low cardinality. So regardless of what the eventual shape of the high cardinality profile for agents specifically might look like, some basis for the standard would enable us to be more aggressive about trying to figure out what that shape would be.
[00:53:06] Rifaat Shekh-Yusef: Okay. Thanks, Jessica.
[00:53:08] Paul Carleton: Cool. Okay. I'm gonna try to keep rolling the Yeah. Get us going here. So I think this is yeah. This is the last one on clients where, where I think some of the issues we're talking about cardinality before, we also have these kind of friction pressure on our cardinality, identities where if it is, high friction to get a new identity such as a a consent screen or a a ticket to your IT team to go have an admin go provision a client ID somewhere, then it kinda collapses down to lower cardinality things like one shared API key, which is not great. And then the, so a solution in in that vein, or, that that's a a problem we have is just, like, currently getting a, getting an identity a high cardinality identity is is is too high friction. So one one area is this is the the draft of workload identity assertion grant where we're talking about just in time and high cardinality identities. Cool. Okay. I will let, I think we've chatted a bunch of our principles. I wanna get over to scopes to get Nick some time to to chat through that. But if we wanna talk about more principal stuff at the end, we can. Okay. I think can I hand control over to you? Where is that?
[00:54:36] Rifaat Shekh-Yusef: I can do that if you need to.
[00:54:39] Bhavani Garikapati: You can. You drop it onto Nick's. It looks like a little piece of paper.
[00:54:45] Rifaat Shekh-Yusef: I just gave him.
[00:54:46] Nick Steele: Oh, cool. There you go. Alright. Look at that. Easy permissions. Hey. Okay. So here to talk about scopes. So currently, right, like, we we have we we kinda when once once an agent is authorized and does all the, like, provision, it's it's it's allowed to reach things. We've gotten to the point that it's, like, reaching the client even before. It's like we have these scopes in place for what it is allowed to do once once it reaches some some resource. Currently, it's very broad, and it's also evaluated ahead of time. And and often, there's a lot of variance in both the, like, support and provisioning of those scopes. It can happen happen in multiple places. It can happen in one place. It can be assumed from from a diff a a different provider of of sort of, like, know, with with, like, cross app access and you may and and and amended to. The the plat like, platforms can also offer, like, additional scopes in this way. Right? So it's like, if you use a connector layer, you can declare scopes that are not necessarily the same scopes that might be enforced, but then use those to make a certain amount of decisions. This can cause, like, additional confusion on, like, how these are provisioned and where the authority actually lies to enforce these. And, again, kind of, like, leads to the the decentralization of of this. And then in order to, like, compensate for for broad scoping and and lack of sort of, like, norm normative amount of scopes, and there there's off there's often a lot of usage with, like, other tools, other security boundaries, other other means of enforcement to to help sort of balance out the the lack of support there. So there we go. There you go. Yeah. So and, also, you know, the the core of this too is, like, one one agent can have a lot of different configurations that might need access. In order to review a change, resolve some changes, update discussion, might need, like, broad GitHub access and then very limited Slack Notion Jira access that you just basically to, like, write to a single instance. And the way Slack Notion and Jira handle these scope wise and and, like, authorization wise are are are not consistent across across the board in some cases. And so being being able to, like, assign these these scopes and permission sets usually require, like or require a role to be created or, you know, some some idea of what the agent might be trying to accomplish ahead of time. And this works in some scenarios, but in, I'd say, more, you know, like, long long lived personal agent flows where thing things might be a bit more dynamic. We we we tend to we tend to over scope, and we it also becomes a lot harder to provision a a one size fits all role, with permissions there. And a lot of the time, we want we wanna go through this, like, one assignment phase where it gets the the permissions it needs. And, ideally, it only needs to go through this sort of, like, consent authorization flow, not so often. And once once it's, you know, mid task or towards towards the end of a task, we would like these, we would like these permissions to be able to resolve. Like, we it it it it becomes a lot more friction if you have to add always allow if you if you have to add additional permissions toward towards the end that aren't associated with, like, specific actions, you know, the high risk flows that George was talking about where it's like, I've contacted my back bank. I'm doing things with my bank, now I need to make a bunch of, like, additional consensus. Like, those to me are are, like, you know, needed necessary in a lot of forms, but we'd like to be able to get from from there to there without, like, having additional incremental authorization steps that that might be decided upon or enforced if if the client was had better context in between. So general generally, when we see, you know, deployments today, these are kinda it's like some some of the pieces that we see used in in in configurations where you have an agent, and we'll just say, hey. Handwave agent here, right, that will defer to a connection manager or connection config of, like, knowing how to talk to some resource. And it'll work with an identity provider or something providing, like, authorization for it to to to make and manage it or have have a set of scopes that that it's gonna use to to negotiate and talk with that resource. There some some enterprises use something like an off proxy where these the identifiers to which these scopes are are are attached might exist in at at at some other layer, which can add, you know, additional complexity here, but doesn't necessarily impact the the user in a lot of cases. And, again, this is kind of like an enterprise specific flow. And then more recently, we started to see better usage of of classifiers, guardians, local or or remote smaller models making some of the access decisions necessary to that that are sort of unrelated to this to to scopes directly. And in, you know, in in some cases, they they might be able to see that, like, oh, well, you're just allowed to read read, write, do these things. But then it's like taking the taking that context, taking those permissions, making a decision about what it's actually allowed to do in order to kind of help deal with the the the broad permissioning side of this. So gen generally, there's sort of, like, three phases to pilot or to to that that organizations kind of roll these out in and some sit in these in certain buckets for for longer than others for, you know, business reasons, trust reasons, PRC purposes. The first is that we kind of have this, like, always ask phase where folks might deploy a harness, call it code, codecs with with a model. And then every time it needs to to to be provided access or perform some action, the user is alerted on this. And this can be incredibly high friction. In fact, this could you know, it it it it could cause more work than if someone was to to just perform a task on their own. Sometimes you can use this with, like, allow for this conversation or always allow for some period of time. But, generally, the always ask flow tends to be a, like, a lot of speed bumping early on on the client side, and then that's, you know, in addition to addition like, other other consent consent and authorization flows it might experience down the road. Then we have approved like, approval pattern flows where maybe they are using MCP cross app access really, if you like, effectively. They the organization might have, like, this tool you know, this tooling in place. And and this this often, like, decreases the need for for human intervention, and we still have we we still have these up, upstream consent flows, fact factored in here. And then eventually, we get into flows, right, where, we can have more granular enforcement, but then enforcement is is mostly put on to to, like, a a a guardian or or, you know, auto mode system that is able to, like, make some of those the the decisions around what the agent might need to do with the context that it has within within some window. So even in the case that it is, you know, it had has the right the right scopes or at least the scopes that should get it across you know, over the line on, from the client to the resource, the client can make additional decisions about whether it's allowed to reach that resource before it even hits some, you know, authorization gateway. There's also kind of, like, I I'd say, an unwell, unhappier path flows where we might have deployments that just have blanket approval. This isn't, like, in in entirely useful in in in most flows you'll see. I I I think that there there's some very, like, small contained flows where it could be helpful just to deploy with with with the model allowed to access a finite set of things. And, again, it's, like, not great when you have to do, like, return augmentation or resource augmented generation. You also have have flows where identity is entirely consumed, and this kind of is is the flow where an agent, for all intents and purposes, has my identifiers and was able to go and and essentially, masquerade impersonate me on on the Internet and then reuse some of the, like, I I guess, what, like, infrastructure already in place, but this isn't, like, an an ideal deployment either. And then you have an agent guard only mode where, basically, you you say, like, okay. It can do anything, but we're just relying entirely on this other risk decision making construct to to get around the fact that, like, you know, the scoping doesn't might not mean a whole lot on a system that or or on a resource where only, like, you know, the the options are rewrite, delete broadly. Yeah. Scoping scoping and and how they're how they're specified by the service cannot can also be pretty broad. It's hard there's not a ton of well, they're they're it's hard for for a lot of resources to identify specific objects within within a set of operations, especially dynamically. Generally, this is accomplished with, like, other, like, OAuth steps and more discrete access tokens rather than having, like, scopes that are tied to specific specific sets of objects. And most of the the the big thing here is, like, most of the enforcement still remains client side. So even in the case where we, you know, we're we're using Guardian model, we are we we we have we have scopes, and we have we have access to this resource. The the decisions around when it's allowed, you know, when when it's allowed to do that read are largely enforced by the the harness or or the or the client in these cases. So when it when it sends off a read request to to to GitHub that we like, that is evaluated entirely locally rather than sent along for evaluation by the resource where GitHub might be able to make a more contextually aligned decision around enforcing whether whether or not it's allowed to read that thing. So I think a more ideal flow of, like, where we could end up for a lot of this, right, is is having the the agent be able to make the make requests within within some broader scope that provides context to help the resource make a more granular decision alongside the authorization service that that helps issue and enforce. So yeah. So to distill it down, right, you know, the the scope is broad and the enforcement is too narrow and that it just sort sort of sits on the the the a lot on the on the client enterprise side when I think the resource can be much more involved. And an agent can the configuring the agent and provisioning that agent with the roles it needs, with the scopes it needs off the off the gate can be can be pretty difficult, especially if if the task, the session, you know, some of that that client potential client information that that Paul mentioned, right, might change pretty broadly. So being able to continue to give them the access they need, especially in in in inflows where, you know, they go from working on something to GitHub to making a website to buying shoes. I don't know. It's always shoes. That being able to, like, move between between those decisions and and have the resource have what it needs in order to accomplish all that consent is is is still not there yet. So yeah.
[01:06:44] Rifaat Shekh-Yusef: Okay. Thank you. Dick?
[01:06:50] Dick Hardt: Hey, guys. So I like seeing that you think more context needs to be going. We need more context at the resource. Curious on a couple of things that, you know, we're working on in payoff. One of those is, per call authorization. Right? That it's not, oh, you're allowed to call this API. It's like, well, what are you trying to do? Which call what what's the agent trying to do? Which sounds if you go back to your other picture, it sounds like that's what you're trying to do is, like, that the context of the call goes to the resource. Am I understanding that right? Like, that that that's really what is the agent trying to do to decide whether or not it should be able to do it or not? Nick?
[01:07:40] Nick Steele: I'm sorry. What was the question? My brain is incredibly smooth. I'm I'm
[01:07:45] Dick Hardt: Go back to your earlier slide. Yeah. Right. So here Oh,
[01:07:52] Nick Steele: there. Yes.
[01:07:53] Dick Hardt: Yeah. Yeah. So, like, you're trying to go and have more context to the resource. So the resource can decide whether to do it. Yes. To which would be kind
[01:08:01] David Waite: of more of
[01:08:01] Dick Hardt: a per call, but it's not like, oh, I can just do right. It's like, well, it depends on what you're trying to write.
[01:08:08] Bhavani Garikapati: Right?
[01:08:08] Dick Hardt: Yes. Yes. That's exactly course. Yeah.
[01:08:11] Nick Steele: Yeah. So it's way too course right now. If we're if we're able to, like so I I think that there's, like, two ways this that this can be applied. Right? It's like, one one is one is we in as as part of the request, there's a certain amount of of contextual information that it that it that is passed along as well. I know that there is, like, efforts with with, like, and Cozy to, like, build this sort of, like, contextual graph or mapping of, like you know, as a a a request and a task might have multiple resources that it's talking to, and they're working to decide sort of, like, coordinate that that sort of task set or that session into something that provides that context. But, yeah, I mean, like, being you you you cannot like, the resource or the and and or the authorization service should be able to sort of, like, build that mapping, and we should be able to, like, either enrich it or, like, wholesale be like, here's everything you might need need to know in order to, like, make this more granular read break decision. But, like, where where that context, like, lives and how it's enforced needs to move more towards the the the the remote sort of, like, resource side of the house rather than have everything be enforced sort of, like, within within the client, the client voucher. Yeah.
[01:09:25] Dick Hardt: Well, I'm just also wondering just from a use case point of view, the the I mean, the resource only knows the context of that one particular call, but wouldn't the context of all the other things the agent's been working on be important at times for whether that makes sense or not. You know, like, the the use case I talked about is, like, the drop table. Right? Dropping production is probably a really bad idea, and the the database would say dropping production is always bad. But if that's one of the steps that's happened after you've migrated to a whole new database because you needed to change the schema and the migration's done, so dropping production then is okay. But the resource, the database doesn't know that because it doesn't know all the other things that the agent's been doing.
[01:10:10] Nick Steele: Right. And and maybe, you know, I'd I'd I'd I'd think the the quickest solution there too would have the resource go and defer to some to some authority to to to make to to get that or to get that context or at least get that to to help with that decision Mhmm. Rather than, you know, rely on the the sort of, like, the the the small the the narrow set of context or sort of, like, the scoped context it might it might have for what it's been operating on. Yeah.
[01:10:44] Rifaat Shekh-Yusef: Okay. Jonathan.
[01:10:48] Jonathan Rosenberg: Yeah. Stay here too is I had a similar question as Dick. But in my mind, what you're asking for here, just to sort of make sure I'm understanding your ask correctly, is is the OAuth model is is largely about the user first gets permission and then the action gets taken. And if the permission's been granted, the action's approved. Is this basically saying and I think this is what you're saying is we're gonna flip it on the head. We're gonna try to perform the action. Then based on the context of that action, we'll we'll request approval, including perhaps in asking the user. And that is that what you're asking? Is sort of a change in the sequencing of approval versus or or authorization and then action, and and it's action then authorization as opposed to authorization and then action. Is that is that what you're sort of wanting to do here and and Paul?
[01:11:40] Paul Carleton: Yeah. I think I think so. I think, like, the the I would I think as Nick had in the or or one of other slides was, like, the evolution we see with client side tool approvals where you start off, you know, approving everything as it comes up, which would be, like, you know, equivalent would be like a no offense and screen on every action, which is, like, way way too much, and people are really annoyed by that. And people, you know, people just started hitting, you know, yes all the time. It's super annoying. Then, like, one, you know, step more is you have patterns, and so you, like, have pattern matched and preapproved a bunch of stuff, which is more like, you know, nicer scopes and things a little bit better configured. And then I think what we see is the next evolution is, like, auto mode and Claude and the Guardian stuff in ChatGPT. Again, this is all client side, but the actions are run through a classifier taking into account what else is happening in the session. And so that, like, I think what we're reaching for is, like, the analog of that, but on the resource side.
[01:12:37] Jonathan Rosenberg: I see. So you don't see the user in in this that's that's helpful. So in this model, you're in this picture here, the user is not getting this this this is not the user approving a reaction. Somehow the user has how is the user's desires handled in this picture?
[01:12:54] Paul Carleton: I mean, if you if if we're mapping the it to, like, the auto mode cases, it's like, you the first pass is by the classifier. And then if it, you know, decides it needs more help, then the then the user gets gets flagged.
[01:13:08] Nick Steele: No. I think I think that this also you know, it's the user's desire is important in some of these flows. I think that there's the more the the a lot of the the the the the plan like, the the hope around the hope around, like, how this could work, right, is a is a flow where a a agent could be provisioned that is, you know, essentially provisioned on on behalf of a team, a company, and, you know, an enterprise, and it's able to accomplish some action with, like, minimal you let less direct user delegation, but a user can can be in the loop for for decisions, especially, you know, in in these these high assurance flows. So being able to have, like, read scopes, write scopes, delete scopes that were have certain author like, that align with the desires of of of the user of the enterprise is important. So and being able to present those with, like, it is allowed to do this if it has, like, a a provided a certain like, these sources of authority to do so is is something that's lost in the mix too. Something that, like, you know, works today a lot with with the Guardian and and and sort of, like, you know, agent guard flows is is that if I outright if I explicitly say, I approve you to go delete the production database, in a lot of cases, a Guardian will say, well, the user did say I approve him, you know, the or it the the agent to go and delete this this database. That decision now leaves the context of the client, and it's up to the scopes and the authorization service. The resort it's it's up to the it's up to the upstream to say, even though Nick approved that, that, you know, that's against the desire of of, you know, the the enterprise is not what it's scope to do. So it's not allowed to do that. And, you know, there yeah. We need we need we need to be able to take take a lot of, like, the the decisions of of other, I'd say, like, authorities into into account here, and that could be the user. That could be a a team. It could be you know, if it is going to delete something and needs it might send a Slack message to a team and say, hey. One of, someone needs to approve me to do x thing. But being able to create that enforcement event upstream is is is something that is, like, really lacking today. It still kind of becomes the own like, the onus is now on these, like, interim authorization services to orchestrate getting all that additional authority.
[01:15:41] Jonathan Rosenberg: Right. But I think at the end of the day, I do think you're saying the that the answer to my question is yes. And the answer was in the original original OAuth concept, right, you'd pre you'd be preauthorized for some set of actions defined by the scopes. Once you have the token, you could take whatever actions you want within the balance of those scopes. And there was no further approvals downstream once the authorization is granted prior to the actions being taken. In this new world order, we're gonna take actions, and only after the action is taken, we're gonna wait before performing them. We're gonna seek some form of authorization. So authorization follows action as opposed to action following authorization. That was my question in this model, and and I think you're saying yes. Yes. It moves
[01:16:23] Nick Steele: towards it's it's more about, action settlement and then sort of, like, out of the upfront approval.
[01:16:31] Jonathan Rosenberg: That's right. Yeah. Yeah. Okay. Great. Thank you.
[01:16:34] Rifaat Shekh-Yusef: Okay. Omri.
[01:16:39] Omri Gazitt: Yeah. I think, Nick, you already mentioned AuthZEN and COSE. But I think generalizing, what you're saying is that, authorization in the real world today in the context of agents really happens in two places. It happens, at the authorization server, and it also happens at the resource server for, you know, many scenarios where, coarse grained scope is not enough to determine whether an agent can actually access a fine grained resource. That's the scenario that you're talking about. Right? And so, I mean, that that exists today in a lot of systems. You know, in Google Drive, for example, you first need a read scope, against the drive, and then you also need to have the subject has to have a particular relationship with the resource, the document, or the folder in order to be granted access to that fine grained object. And I think perhaps you're asking how these worlds connect, you know, because today, you know, how I provision, how I share a Google document with some other subject, for example, an agent, is, you know, kinda specific to that particular back end. You You know, it all hides behind the resource server, and there's not really a standardized way to represent entitlements and ownership and sharing of those resources. Certainly not in a way that flows all the way through to the OAuth consent layer. In your, you know, in in your mind's eye, do you see a user model, you know, back to Jonathan's point, where the agent asks the user for, you know, right access to a particular document, and that flows all the way through to establishing a relationship in the Google system between that agent to the document for a limited amount of time. Is that how you you think that that scenario ought to ought to play out? I'm just curious how how you, you know, would propose kind of trying to have these worlds talk to each other.
[01:18:57] Nick Steele: Paul, you're you're you're free to take that first, and I suggest know, feel free to keep me keep me honest, but, yeah, no idea.
[01:19:10] Paul Carleton: Sorry. Can we Oh, no worries.
[01:19:12] Nick Steele: So I think the way it's gonna be yeah. And, yeah, just just to try to take keep keep me honest on this one. So I think the question was, like, do we do we see
[01:19:19] Paul Carleton: do
[01:19:19] Nick Steele: do you
[01:19:19] Paul Carleton: see a feature where it's,
[01:19:20] Rifaat Shekh-Yusef: like,
[01:19:22] Nick Steele: the agent is provisioned or or is, like when it accesses resources, like a like a like a a Google Doc that that sort of request is is sent upstream and then, like, authorized and stored by by Google as sort of, like, the resource of, like, yes, this connection access. I think in a lot of cases, this flow kind of I I mean, goo Google's a a heck of an example, but, like, you know, when when when the when this is, like, relationship is established, it's usually not toward like, it's not specific to a document, specific to a set of documents. Like, it's a it's a Google Drive. I think that's, like, gender generally, that's a lot more of, like, a it's a lot more of a a, like, helpful space to work in where it's like, it's allowed to access this set of things, maybe not a discrete thing. In some more high assurance systems, you probably want it to be a a set of one. And I I I do think that it it would be helpful, especially on on on the Google side to say that there is, like, a, some existing relationship between this agent, this user, this, you know, this resource to be established, and that might already exist in some format either through, you know, like, through through through OAuth already. Right? It already has some access token that allows it to go and talk and and and request additional things from Google. And I think that's help like, that's that is a helpful baseline context for that resource of being like, we have already had some sort of relationship that is established that this is accessing something on my behalf or is, like or is has some relationship already with with an enterprise. So then when it goes and act it requests additional access or, you know, specific x readwrite to to this one to to this one resource, I yeah. I I I I think that that should be a a fairly, like, easy process to be verified and stored by Google that it's like, cool. It now has additional access, associated with this with this grant.
[01:21:10] Paul Carleton: I would just add to that. I think the I I I think that that difference between the scope and the the resource does, yeah, does exist today and and at Google. But I I think the thing is, like, what are you granting that scope to, or what are you granting read access to that particular document to, is the thing that we're talking about of, like, is that a, is it, like, a short lived principle that you grant that scope based on the intent of a particular, you know, session or conversation or something? Like like, that is where I think we would would like to get to is be able to say this principle only has access. Like, it's trying to read this document. Should it actually be able to read that document based on what the user intended? And I think that's that's the thing that doesn't, like, giving that context to Google, Google just knows, you know, this this this service account has agreed access to this document. It doesn't necessarily know or have any ability to ask, like, did you actually meet for that to happen?
[01:22:21] Omri Gazitt: Okay. So just from what I'm hearing you saying, it would be nice for the existing consent mechanisms in OAuth to extend all the way down to fine grained resources in a resource server. So that way, there's kind of some semi standardized or reasonably standardized way of being able to, you know, kinda take, you know, kind of general read for documents and be able to kind of fine grained it to this agent can read this specific document and write that particular document for, you know, perhaps a limb.
[01:22:57] Nick Steele: Yeah. If there is, like, an object identifier, right, that is associated with the reason. Yeah.
[01:23:02] Omri Gazitt: Today, that that's not the way it works. Right? The, you know, the it's it's too difficult to provision access to a whole bunch of resources at token issuance time, you know, when you log in to the Google Drive. That's why, you know, Google Drive has these two mechanisms. One, you know, at the, you you know, one one more coarse grained, you know, having to have a scope to access the service to begin with. And then, you know, at the resource server, they have their, you know, kind of famous Zanzibar system that can actually adjudicate whether this subject has a relationship or can actually perform a a you know, has a permission on a particular resource. And I think what you're saying is, you know, for agenetic scenarios, it would be nice to have the ability to have an OAuth consent write a record in the, you know, Google's end of in Zans of our system to allow that particular agent to access this particular document, perhaps for, you know, the the extent the the the length of the session so that all of the existing consent mechanisms can essentially flow all the way down to fine grained resources. I think that's what I heard you say. I'm just wanna make sure that that I heard you correctly.
[01:24:12] Paul Carleton: I I think we're maybe a little bit higher level or just, like, stating the problem. I think, like, that what you're describing would be one approach to to solving it. But I think that, like, another flip would be you you're not writing in a consent screen or a consent time, but Zanzibar has a way to reach back out and and and check this context, if that makes sense.
[01:24:35] Rifaat Shekh-Yusef: Okay. Thanks, Omri. David?
[01:24:41] David Waite: Let's see if my audio works. Okay. Yep. So I would say access tokens are useful for fine grained and coarse grained authorizations. They they're just the key to get in, but OAuth is mostly a way to get delegated access to the resource owner's permissions and not necessarily a way to further delegate that. So for instance, if I access Google Calendar, I can get read access to calendars. But once you start saying, need to have read access to a specific calendar, it it's really more domain specific. An authorization server typically isn't going to know things like the the current rooms that exist or channels that exist within a Slack. And so people have, of course, implemented their own thing, but this really sounds like to me more of a problem of needing to orchestrate systems, needing to dynamically get access to systems that may have built through and spoke mechanisms to do fine agreeing access and trying to create something that provides a better user experience and a more uniform way to to be able to do that kind of fine grade access. But it we're probably getting outside the realm of scopes. Even something like RAR might be challenging just because of the dynamic features of the resources that the authorization server just isn't going to know what files and folders exist in Google Drive. It's the Google Drive that knows that.
[01:26:27] Rifaat Shekh-Yusef: Yep. Okay. Thanks, David. Jonathan?
[01:26:32] Jonathan Rosenberg: Yeah. I mean, I think in a lot of ways that the word authorization service in this picture is is confusing things. Because when I hear the ask from from Nick, you know, it's it's not that we want a different way to do authorization. It's that what we really want is an approval service. We want a way where this what I was trying to say before. Instead of first granting authorization for some set of actions, and then once granted, the agent can do anything, you know, in the context of those authorization that has been given. Instead, we're saying, let it take the action. Go for it. Try it. And then given all the context behind it's that attempt, you know, there'll be some decision that gets made, whether it actually requires a human in the loop or whether it's through some guardian or agent or a posting a Slack channel that allows a group of people to perform the approval. Then once approval is granted, that action is taken. Then the difference in my mind between the approval and an authorization is an authorization is ahead of time, and approval is after the action. An approval is just for the thing you're doing now, not a grant for lots of things in the future. So so that's again, I'm trying to understand if that's the ask, because it's it's it's certainly, it's different protocol machinery. And so but that's still that seems to be what I'm hearing. And that's a lot more than just the granularity of scopes. It's the entire sequence of how we make decisions.
[01:27:54] Rifaat Shekh-Yusef: Okay. Thank you, Jonathan. So we're running out of time here, so I'm gonna get Pieter a chance here.
[01:28:03] Jessica Trochet: Thanks,
[01:28:05] Ni Yuan: Yep. Thanks, Rifaat. Just wanna say, think this kind of new pattern makes sense because throughout our observations and discussions with some leading payment services in China, and they kind of exhibited a similar practice or behavior where there's, like, a preapproval process. It's more like let me give you a example is that, actually, when a when a agent is trying to purchase something, a purchase order was first approved, and then this is sent into some settlement services. And when an actual payment request is made, it's not merely, made upon to this request. It's actually compared against the previous purchase order request that was approved by the by the by the initial user. So I wanna say that this kind of preapproval thing with a conditional enforcement or executional condition. So this is some kind of a preapproval thing plus the the actual enforcement. So this kind of a these two requests or approvals does not have to be strictly sequential, does not have to be strictly synchronized. It could be asynchronized. It could be, like, a long term plus a short term enforcement. But, indeed, I see similar good practices that coincide with many different places. So I'm I'm gonna say this might be a grant here. Thanks.
[01:29:46] Rifaat Shekh-Yusef: Okay. Thank you, Pieter. Karl, you had a you want you were in the queue there. Do you do you have a quick comment, question?
[01:29:58] Bhavani Garikapati: I we I think it's a not nothing that we
[01:30:00] Karl McGuinness: need to address right now at the end of the call. It's Okay.
[01:30:02] Bhavani Garikapati: There's a there's chat just calling out that there's existing work stream in AuthZEN that's doing exit this
[01:30:08] Karl McGuinness: new request protocol that people are asking about to do just fine grained approvals, there is an existing standards organization that's addressing that through the AuthZEN side.
[01:30:18] Rifaat Shekh-Yusef: Okay. Awesome. Thank you, Karl.
[01:30:19] Nick Steele: Yeah. And I
[01:30:20] Rifaat Shekh-Yusef: I wanna
[01:30:21] Nick Steele: oh, sorry. I just wanna say, like, I echo Paul's point too and and what other folks have said, like, you know, Peter in the chat, right, where it's like, we're not putting all of the the the the weight of these problems on onto to Oauth. I think this is gonna, you know, require a concerted effort across the ecosystem. And as Karl said, now there's already groups working on this, like, in with with within and and elsewhere. And I think that there there's a lot of other components in play. I'm, you know, very interested in the credential management side side side of things also on, you know, like, what we can be doing with with with spiffy spire and and, you know, the the work with AIMS. Additionally, you know, it's like what what we need to do and what can be included in in OAuth to help better support support these approval flows is part of it, but, you know, it's it's it's a lot of different pieces acting acting together here. So yeah.
[01:31:07] Rifaat Shekh-Yusef: Yeah. There was a there's a question from George here about resource being itself an LLM. So, George, do you wanna say a word about this? Or did we lose George?
[01:31:28] Nick Steele: I see him. I see him on the call.
[01:31:30] Rifaat Shekh-Yusef: George, can you hear us? Okay. I
[01:31:35] George Fletcher: Yes. My apologies. Yeah. I I think that there is this situation that so often when we look at these problems, we look at them within the synced context of a single domain. Right? Just the enterprise. But I dare say that the vast majority of deployments within the enterprise are going to hit something where it needs to talk to Salesforce. And it it may not be the client on the user's device that's talking to Salesforce. It's something within the enterprise that's needing to talk to Salesforce. And there is some work here in the OAuth space to deal with this, but I just think we we're going to do ourselves a disservice if we don't consider these chain scenarios and basically assume that we can solve this, you know, within a single environment. And then it's just going to magically apply as you go across trust domains because, fundamentally, we do not have the same language within across trust domains. So the way you talk about principles, way you talk I mean, Karl has a post about the fact that when you cross these trust domains, the the subject identifier changes, and that's a mint. For some for somebody in the main first trust domain, it's a mint to create a new thing that identifies the the subject identifier in the second domain or some other way to to find the right one, and it goes on. So I just wanna make sure that when we think about use cases, we don't just lock in against just a single sort of trust domain, but we look at how does this work across multiple trust domains and what does that mean. And when you start talking about human in the loop, it gets really fun.
[01:33:15] Rifaat Shekh-Yusef: Yeah. Okay. Thank you, George. That's a great point. So I'm gonna end it here. Thank you all. Great discussion, presentation, Appreciate it. And I'm sure we'll have more time to discuss this. Deb, did you wanna say anything here?
[01:33:33] Bhavani Garikapati: Just that your notetaker deserves a gold star.
[01:33:36] Rifaat Shekh-Yusef: Yeah. Absolutely. Thank you. Thank you. Thank you, guys.
[01:33:40] Bhavani Garikapati: And it was a it was a good interim. Thank you very much for that.
[01:33:43] Rifaat Shekh-Yusef: Yeah. Awesome. Thank you all. Appreciate it. Bye.