# WIMSE Interim {#wimse-interim} June 03 2026 *notetakers: Noah Stride, Justin Richer* ## AI Agent Authentication and Authorization draft {#ai-agent-authentication-and-authorization-draft} Six edtors: Pieter, Jeff, Brian, Nick, Yaroslav, Aaron * Pieter: * First question: "Why does the draft exist" - era of AI, lots of fear/uncertainty. Illusion that everything is new. * Before we can reason around authz, we need to solve identity. * Tendency to invent new "AI" protocols. * AI is software - we are not starting from scratch. * There is no single solution to all of this - wide range of technologies needed (identifiers, authn, authz, monitoring). * No current organizing framework that embodies all of this. * Focus: what bits are missing? can we surgically target those with future standards work? * Agents /are/ workloads - this is why we feel draft is relevant to WIMSE. Interacts with LLMs, users/other systems, tools/services/resources. * Draft tries to avoid inventing any new standards, maps mostly IETF technologies to capabilities needed for agentic identity stack. * Key building blocks: SPIFFE, OAuth, WIMSE, SSF - how to fit them together. * Yaroslav: * Identifiers: foundation for authn, authz, delegation, audit etc. Workloads need stable, verifiable identifier. * Proposed: WIMSE identifiers (often SPIFFE - subset of WIMSE) * Credentials: Authn, authz rely on credential not bare identifier. Cryptographic proof of ownership of identifier. * Proposed: Work from WIMSE S2S (X.509/WITS) seem to fit well. * Provisioning: Very infrastructure dependent/platform-specific. * Proposed: SPIFFE / although other options may be needed (due to platform-specific native). i.e for end-user MDMs may be used for posture assessment. * Authentication: authn to llm, tools, services, resources, other agents. * Proposed: WIMSE S2S mechanisms (mTLS, http message sig, WPT) - avoid static pre-shared credentials * Brian: * Authorization: specifically, delegated authz. already provided by OAuth. What an agent can access, is it acting on behalf of user/self/other agent. End-user may want to authorize agent to act on thir behalf. * Proposed: Maze of OAuth specs (some standard, some on way to standard). Document shows how to use these existing OAuth mechanisms for specific usecases. Jeff/Pieter: Workload Identity Federation (from chat): * https://developers.openai.com/api/docs/guides/workload-identity-federation * https://platform.claude.com/docs/en/build-with-claude/workload-identity-federation * https://docs.snowflake.com/en/user-guide/workload-identity-federation * Brian (cot'd): \* Authz code flow/client credentials for delegated user flows - directly on behalf of user. \* We need to identify areas where work is needed. \* Includes body of work on security best practices. Apparent simplicity - but many security edge-cases here. \* Token exchange - fairly abstract but useful. Can encompass multiple tokens exchanged for single token. Can be profiled in useful ways - identity chaining across domains. Tied thru to ID-JAG. \* Transaction tokens - convey user and external client authz/context info thru call chain of backend services w/in single trust domain. \* Human in the loop: authz code flow, og human in the loop (very early in loop). CIBA/MCP user-soliciation - message flow/structure of CIBA doesn't map well due to client initation for mid-execution approval. \* Later stage human approvals may be better suited at applications layer - some debate here. \* CIMD is emerging within oauth and may prove useful for dynamic relationships. * Jeff: * Monitoring, Observability, Shared Signals: * Risk evaluation, things may no longer be accurate - authorization may need to change. How to propagate this. * Want to avoid reinventing the wheel - OpenID prior work here is useful: SSF, CAEP, RISC. * Auditing of critical details -> revoke credentials, trigger new cycle of evaluation for issuance of new creds. * Pieter: * Policy and Compliance * What is config/rules (policy), measuring against that (compliance) * Very deployment specific - not pointing to any specific standards. * Brian: Next steps before Vienna - Is there interest in pursuing this work (from the WG)? Is this WG the right venue for that work? ## Discussion & AOB {#discussion--aob} * Justin: Opening up for discussion of these questions posed by Brian. keep in mind: WIMSE already has a number of documents on the docket that we need to ship before IESG will let us take on more work. Lots of work is nearly there - needs more reviews. * Yaron Sheffer: It's a definite yes from me. It seems in scope/should be in scope for WIMSE. We better get to it asap. I am working w/ author teams to try to finish existing deliverables. Main concern with proposed document is the interaction between WIMSE stack and OAUth stack - is not clear esp in terms of authorization. Feels more like shopping list of standards. We will need to clarify whether WIMSE can standalone, whether OAuth can standalone, and how they interoperate * Flemming: Also v interested in the work - feels needed/promising. Open question: How the work relates to ACP group (assuming this is formed)? At interim ACP, it feels like there is a need for framework. Let's make sure multi-agent agent chaining is covered. Step back - what are the actual requirements for solution? * be clear on mechanisms (multi-chain scenarios) * *Justin: Context - we are not asking if this is ready for IESG, we are asking if this is a useful problem space to tackle within WIMSE? If we do decide yes, then we will meet separately to adopt this draft as starting point.* * Joseph Salowey: Yes, I think this is important work to pursue, WIMSE seems right place. It definitely feels like a big area - systems, AI oriented or not, will benefit from more structure in this area. * Yaroslav: As co-author may be biased, but I do believe this is a good-fit for WIMSE and an important problem. BCP doc is actively being reviewed/addressed, hopefully this will make space soon for this work on this draft. * Paul Carleton: Feels like super important problem to solve. From MCP side every conversation with enterprizes is asking about how to handle agent authn. This draft seems to give common ground to work from. One request: for delegation, if we can get really specific/example deployments, that would help a lot. * Yaron Sheffer: One of my main concerns with section 9 is that it's not clear whether WIMSE stack can fully cover use-cases, or if OAuth is needed for critical pieces - i.e for calling tools/mcp for intra/inter domain. This would need to be eventually clarified before wg last call. * Pieter: Good comment Yaron. There is comment in doc on authz being more than OAuth. Often orgs will have multiple authz in play. This can definitely be fleshed out/made more specific, give understanding this document is from practitioners pov. We should leave a gap for how orgs can fit existing infra in. * Justin: (chair hat off) - one of trickiest things for work like this to make sure it fits itself well with use-cases it works for, and avoids those that it does not. "When your agent looks like a workload" - what does this look like? * Charles Eckel (AD): As an individual, I'm supportive of this work - seems like WIMSE is a good place to work on it. With AD hat on, based on my read, this more or less falls into the spirit of WG charter. Not clear from work items specified in charter that this would be one of them. Helpful to ietf community to adjust charter, make clearer what is/isn't covered - even if not necessarily required. As said prior, we do need to make sure WG gets work off the queue before we add more. * Justin: As chair - I have similar take. I believe we can add specific work items without recharter. As wg, we need to figure out what our intended landing point for this would be. * Pieter: I think it does fit in WIMSE. In our charter/deliverables we do talk about BCP documents. Very explicitly this draft does not define any new protocols. Though, there is new work falling out of this spec from the gaps. If this is best practices type document, feels it fits. We have interest/right people. Draft is little strange in that it spans wgs, but it feels needed as something for people to anchor on. * Flemming: Responding to pieter, are we pre-supposing that the work wouldn't propose any new protocols/machinery and restrict to only profiling? * Pieter: From pragmatic perspective, from the level of attention needed for a new spec. There will be multiple ways of doing things - some of this work may fit better in other working groups. I don't think it precludes WIMSE from taking on other work items (i.e cross domain use of txn tkns - maybe that needs to come into WIMSE). * Justin: I think this would be a key thing for WG to discuss (what shape do we want the draft/work to take?). Chairs will send out email thread to confirm interest. Not a call for adoption yet - may need to push more work to IESG/shephard review before we commit to this work. It definitely seems suitable to use the WIMSE mailing list to discuss this work/topic. * Pieter: As chair, I'm conflicted as I think call for adoption may help to focus attention, but do appreciate that we do need to get work off of WG plate. Let's push that work over the line. # Conclusion and Next Steps {#conclusion-and-next-steps} See you in Vienna!