IETF OAuth Interim 3

June 1, 2026

Agentic AI and OAuth discussion

Wide discussion about AI and OAuth since we have many drafts that touch
on this topic & are published within the context of the OAuth WG

George Fletcher:

After 125 + a lot of IDs question to the listserv - is there some way we
should evaluate IDs in the AI space? How do we determine what we pick up
and what we don't pickup? There's too much for one person to read.

I have been collecting & tracking 70+ URLs related to agentic AI &
delegation. We have OAuth rechartering coming up. How to get a sense of
all the work being done?

Asked Claude to find all the IDs that have been submitted that have to
do with Agents & Delegation. Combine with URLs from other places
(LinkedIn, mailing list, etc.). Claude evaluated drafts.

32 in last 6 months - overwhelming amount. What is the process to manage
all this now?

Across 32 drafts:

• Every one references foundational + working group drafts
• Reference WIMSE + scitt as well

5 categories:

• Delegation mechanics
• Agent identity
• Discovery & transport
• Audit & compliance
• Adjacent & cross-cutting

Delegation Mechanics:

7 drafts, all related to delegation. Where are the overlaps within
these, what are the unique innovative pieces?

• Should we look at one spec that relates to delegation and try to
  combine?
• Is it way too early?

Agent IDentity:

• draft-klrc
• WIMSE work
• AIP (multiple people using same acronym)

Can we collapse this to WIMSE identities and be done?
OAuth client Instance Assetion is somewhat different, but has been
talked about in WIMSE. Instance identifier separate from class
identifier.

Discovery & Teansport

DAWN going up for BoF in IETF 126
Discovery is something that is important, if we can push all that into
DAWN and liase with them that could be sufficient. Say OAuth isn't
touching this aspect of deployment at all?

Audit & compliance

kuehlwind-audit-arch - going to be another BoF around Audit?
Rifaat: idk, not familiar with this
Audit leverages ~10 different existing specs & draft specs

Adjacent & cross-cutting

AAuth Protocol
Client Challenge Protocol - new from OSW, can relate to agents but
doesn't have to relate to agents. More about if an RS or AS wants to
challenge client for fresh attestation about the client itself.
Secure Intent Protocol
Many others as weill

Notes:

AIP name is contested by many different authors

Re-slugging is getting more common. Sometimes names were not appropriate
and then get fixed. draft-lastname-oauth-docs will show up on the oauth
page. Needs to be approved by chairs.

Nobody is posting with the incorrect naming scheme maliciously - people
don't know the rules & that is why things are getting renamed.

Some work is composing existing specs (audit). Some work is totally new
(AAuth).

Overall - 32 drafts coming in to the IETF in this space. I suspect we
will get more before 126. How do we manage this all?

Rifaat: WG needs to solve this, otherwise WG will get overrun with docs
over the next few weeks. Does anybody have comments; questions;
suggestions; thoughts?

George: Was anybody familiar with most of the stuff being referenced?
No, it's too much. How many of these are deployed vs AI generated? Is
there value in defining a small ruberic for the WG to even look at a
draft at all? One of the ones I had agreed to review from IETF 125
didn't end up saying anything. If we had a ruberic, we wouldn't have
even looked at it - would have said it wasn't ready. Not sure what such
a ruberic would be.

Rifaat: To get ready for Vienna from a chair perspective, any existing
WG document has priority over any of this. We need discussions on the
list for things that want to get presented, & we need to see interest on
the list. Otherwise WG would be overwhelmend. We should also see people
who are willing to implement and deploy thse things. These will filter
documents out & focus on ones that have people and interest behind them.

Dick Hardt: Idea on Ruberic - we need to define the problem that needs
to be solved & why it cannot be solved another way. Interested in
whether AAuth is appropriate for OAuth as well - there area 3
deployments of AAuth right now, 4 on the way, demo night in a month. Not
sure if traction is there yet but I'm of the view that OAuth doesn't
have the right foundation for what we need. But if OAuth does what you
want to do then keep doing it. For deployments that just need a little
more to get more milage, that is useful work.

Bjorn Hjelm: I thought there was a mix of terminology - people refer to
same thing but call it different things. AI Agent / Instance. There
needs to be a common terminology, and there needs to be problem
statements. George - your email on defining what the problem is before
we define a solution - is extremely important. I am looking at a bunch
of solutions without really agreeing what the problem we want to solve
is. This is obviously bigger than just the OAuth working group. We're
having the same conversation in WIMSE & SCIM. Working group needs to
agree on what the problem statement is to be solved.

Pieter Kasselman: One thing that strikes me is that there is different
work on different timescales. Some pragmatic short-term work on existing
OAuth deployments. Get people unblocked and moving forward. Longer term
- things that will take nearly a decade and have infrastructure getting
replaced. Not the next 6-12 months. Infrastructure is slow to change
sometimes. How do we keep expanding & plugging the holes we find in the
near term? Maybe the exisitng infra needs a bigger overhaul and that's a
long term thing.

Paul Carleton: In MCP/OS world we're seeing a lot of issues & pull
requests coming in with agents having more capabilities. We need a
triage step to get through all of them. Rifaat- you mentioned mailing
list discussions. Are there any other things we could do?

Rifaat - other thing we can do is more interims, instead of taking
valuable time of in-person meetings.

More interims before Vienna? That's an option.

Is polling / voting something we can do?

Rifaat - as a chair, I really want to see specific discussions on a
specific document on the list. I want to see interest & intent to
deploy. Otherwise we have a long list of documents that we cannot get
through.

Pieter - Paul, MCP has this problem too with lots of proposals. How do
you triage those?
Paul - Publish list of priorities. SEPs not in that list don't get
effort put in to them. SEPs also need to be sponsored by a core
maintainer or a regular maintainer in order to be brought along.
Different governance process from IETF.

Rifaat - I want to go back to Pieter's short-term vs long-term point.
Goal of rechartering is to allow the wg to discuss goals. When we talk
about AAuth, it's possible to discuss it within the context of OAuth &
then make a decision after if we need a different WG or if we can
continue inside OAuth. Some people want to extend OAuth to address their
specific niche; some people want a completely new mechanism.

George - Back to this aspect of problem spaces, I've been doing work in
the context of delegation. We need to have a more capable delegation
mechanism than sub and act.sub to represent agents. Having that
discussion at the problem definition perspective is super helpful to
then get solutions. Maybe they're layered on top of each other so simple
things can stay simple. Parent/child guardienship, privacy implications,
don't need to be completely new. I think audit is a gap. Should we punt
on that and say it's some other group's responsibility and only have the
low level bits?

We need to look at the problem holistically and identify gaps.
draft-klrc is a good start. We need to continue that. Identify the gaps,
and then say what are the things short-term and long-term that we need
to fill them?

Pieter: We also need some criteria for why it should be done in the IETF
vs Outside. Other question is what is the scope of OAuth, really? There
is a bunch of stuff outside the IETF as well. Things are being proposed
in all sorts of forums - like OASIS, new SDOs popping up as well.

People self-select - they bring it into the IETF for reasons, but is
that where it belongs? Should all this work be in the IETF?

George: In that spreadsheet, there are many that are outside the IETF.
Work in Decentralized Identity foundation. Academic papers that are
published to research sites. Formal proofs for x/y/x. Stuff happening in
W3C and other foundations that are getting spun up. Within the IETF
itself, there are upcoming BoFs + existing working groups that overlap
each other to some extent. This DAWN BoF & A2A BoF Aaron & Pieter are
liasing with already to make sure they arent' doing authentication and
authorization.

Need to be engaged in ~6 differnet working groups to get a full picture
of what is going on. Some specs of WIMSE have auth components in them.
Not tenable to figure out how to manage it all, even with help of AI.
Even just the 32 IDs in this slide deck are more than I can process.

Rifaat: One of the motivations for rechartering the OAuth WG is to make
this easier so people dono't need to wrap their heads around all of
this.

George: My only concern here is are we getting enough people that are
dedicated to solve these at the IETF level? We can increase our charter,
but if it's the same three people doing all the work, then we're still
not going to get anywhere. If we recharter, we need to know we have the
necessary resources to actually do the work.

Three sessions per IETF? Not in vienna for sure. Not sure if the right
answer. Maybe right answer is more interim.

Pieter: If you concentrate all the work in a small community, it's
reasonable for that to take more time. You get scheduling problems, but
it might be worth the tradeoff. Pushing more work into OAuth and
spending more time on it could be the answer. Maybe more interims are
the answer. Even back when we did 3 sessions, nobody got more than 20
minutes anyway.

Rifaat - someone mentioned terminology. Dick and I started some effort a
long time ago. Is there some interest from the community to address that
problem again? Would that be helpful?

Pieter: Why not - people fall back to terminology. People start these
exercises but they never finish and they never get used. Solving
terminology may not be the panacea we expect it to be.

Rifaat - Terminology meant to be a living document that you can point
at, not a static effort.

Dick - we didn't want to come up with definitions, that's challenging.
Let's go and categorize the identity-related words and point to where
they are used, and try to help people to reuse existing definitions
instead of remaking them. eg. credential is used in many different ways
across different documents. Problem was that changing document over time
doesn't work well in IETF - required us to be in the workstream of
publishing documents.

Not an OAuth WG, wider audience issue. (Security Area)

Pieter - there will be a WIMSE interim on weds to discuss the AI Agent
authz and authn draft. Narrow discussion.