Minutes interim-2026-oauth-08: Mon 17:00
minutes-interim-2026-oauth-08-202609281700-00

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.