Paul: LLM and oauth go together very well Standarizing auth makes these systems secure Nick: Problems we cover today are not theoretical, these are practical problems we see in deployments Nick: We list and define problem spaces, feel free to ask questions about problems, we also will cover candidate solutions. But, picking solutions / arriving solutions is out of scope for this presentation. Paul: Boring Problems sections. These are not agent specific. LLM's are good general purpose for oauth clients, they can be used in many different contexts, in plug and play fashion. Issues like: Integration friction is visible, needs coordination between clients, users and servers. Discovery is important, with zero preconfiguration. On Client registration, previously, we need client developer to test and integrate clients. Now, with LLM's clients are expected to discover and integrate with a server that has never seen before. On MCP, with CIMD, this is a promising direction that reduces this friction. Even with CIMD, we do have some challenges, like the need to have test accounts to test the integration (to determine whether it works). Pieter (Question): Does server refer to authorization server ? Paul: No differentiating here, it is application server, I was referring to. Paul: Next issue is consent screens in oauth flows. Which one of this most valuable, should they be consenting too etc ? Nick: Other issues related to consent, it is fairly decentralized, so a user can cross across consents, many things, in a flow. There is not centralized management for consents. George (question): If LLM is working with 10 different applications, then each of these applications, need their consent flow. I am confused, if we need that to be predetermined across all of these applications ? I am trying to understand where the consent problem is ? Nick (answer): I am not saying we don't need consent across these flows. But, how and where we show them in a cohesive manner is where I am going with it. George: We need to iron out the details, due to bad privacy practices. We need to ensure the user is able to control the flow where they want. Jonathan: Is the problem is that we have too many consent screens ? George: Where the consent needs to live ? Having a central source for these consents,where resources is able to receive the consents it needs. It is less about reducing the power of consents, rather than making it more context driven, and having resource be the decider rather than clients. Ankit: how to manage proliferation of consents, say using short lived consents over long lived consents. Paul: Cross organization consent flow problem exist, which is difficult to solve today. ID-JAG solves this. Krooj: Did you look into \[needs edit\] per-token draft, that tries to address the consent issue. Paul: Refresh Tokens: Hard to remediate issues, because we don't know whether the client is untrusted, or server never grants refresh tokens. This is annoying problem Paul: Access tokens are generally are bearer tokens. They get logged, and we have this general problem of token leakage. Some solutions like shorter lived tokens would help. Phillipe: I am fan of CIMD, but some clients can't host these files. What are your thoughts on that ? Paul: We host CIMD on a remote server and use redirect from localhost. I did post a blog article on MCP that talks about this implementation. Second section Agentic specific issues: Paul: Who is the subject for JWT claims ? Whe have four different setups. Dick: What are we trying to communicate, rather than trying to fit into existing claims ? There is always going to be an agent. What signal are we trying to send ? Nick: These are the primitives we have to work with today. Absolutely, in the future, they can be better identifier, to understand who the agent is. Dick: You might want to know specific instance of agent is also being used ? Paul: The thing I am trying to clarify whether agent is borrowing user's permissions, or using it's own permissions. Jeff: Client ID might not mean something end to end. That's the problem we saw. Paul: Multi-surface clients, deciding when consent can be reused etc can be messy. You might to add metadata and with that we might have cardinality problem. Cardinality mismatches is something we need to solve. Jonathan: Cardinality issue - is it for principals, or for other things too like permissions ? Paul: How is represented in downstream,and also about permissions, project scope. Michael: in KYA token solution, there are different claims for agent platform vs agent instance. We found that distinction useful Ankit: Agent instance is missing (correlated with task/objective) here. Does that become another layer of cardinality explosion ? Dick: We also want to know more about Agent, some times about claude code. What are your thoughts about verification of agent ? More of verification who exactly is the caller ? Michael: Knowing whether the client is running on mobile, desktop etc. Knowing that part of the stack etc would be useful, given the power of agent. Paul and Nick: I agree that is important. Jessica: Because of lack of high cardinality of agent profile, we have to make some compromises Thid section (Scopes) Nick: scopes are broad, evaluated at head of time. To compensate for broad scoping, we use other means of enforcements like using tools. Requiring a role to be created a head of time, tends us to overscope the permissions. Nick: Talked about trust building patterns. Always ask flow is speed bumping, approval patterns flow decrease the human intervention, and in the third level of automode, client can make additional decisions and offload some of these decisions. Nick: Most of enforcement still exists on client side, on when some actions are allowed (enforced by harness). These decisions are evaluated locally. The more ideal flow is I having the agent make request for the authorization service to make decisions using context. Dick: We need more context for the resource. We are working on per call authorization model, which sounds very similar to what you are trying to do. Nick: As per of request, there some context that we attach. We should be able to enrich that. It's where that context lives is important. It should be is on the resource server, not the client. Dick: Talked about Database table drop example to illustrate that resources may not have context. Jonathan: Is your ask: change of sequence, is action and then authorization ? In original, we pre-authorize the actions. Paul: Approving everthing as it comes up, can be annoying. One step evolution is pattern matching, where depending upon the pattern, we pre-provision some of these actions. The next evolution is auto-mode, where we use classifiers to decide. But, all of these are client based solutions. Nick: This is more of action settlement. Omri: Authorization in real-world today in context of agents happens at both authorization server, and resource server ? Is that what you are saying here right ? We already such examples in practice. Eg: Google drive and Google document follows the same model. David: Access tokens are useful for fine grained / coarse grained access. Oauth is meant for delegated access model, this dynamic nature of permissions seems to be outside the scope of oauth was build. Peter: Agree with the pattern introduced today. A combination of sequential pre-access approval and actual resource access is also observed in other running leading agent payment project specifications. An example use case is to approve PO first and then approve a specific transaction. This coincidence may indicate this is a good practice.