OAuth already supports this with credentialled clients. I'm struggling to see any reason why a new RFC would be necessary.
Tim, my ask would be to very explicitly explain why the answers to your questions are not already handled by OAuth. For brevity, repeated here: 1. Which agent is making this request? 2. Who is accountable for it? 3. What is it permitted to do? >From my point of, agent = client, so (1) is solved. (2) CIMD and DCR solve this with a url that points back to the owner. (3) Is never solved by OAuth because what is contained in the token is an identity + claims, not authorization. Authorization also changes independent of the distribution of the token. For associated access there is the scope property, which obviously doesn't address 90% of authorization scenarios. But for those you probably want some sort of Transactional Auth (TxAuth). That being said, there could be some interesting things in the draft such as the KYC expectation (which heavily mirrors ACR for me), but if the highlight are those three questions, I would personally ask for anything that is already solved to be removed from the draft as it confuses the use of OAuth. And then there are things that are just hugely problematic such as sections like this: > All Agent Identity Tokens MUST be signed using ES256 (ECDSA with the > P-256 curve and SHA-256) as defined in [RFC7518] Section 3.4. This > algorithm provides strong security with compact signatures suitable > for high-frequency agent-to-service communication. Which speaks a lot to a misunderstanding of how algorithms can, should, and do work in current ecosystem. The rest of draft skips over the actual technical challenges with the existing OAuth standard, so it is very hard to know if that is due to a lack of understanding of what is possible or a disregard of it. - Warren On Sun, Mar 15, 2026 at 6:42 PM <[email protected]> wrote: > Hi all, > > I've submitted a new individual Internet-Draft proposing an identity > protocol for autonomous AI agents: > > draft-gudlab-agentid-protocol-00 > "AgentID: An Identity Protocol for Autonomous AI Agents" > > https://datatracker.ietf.org/doc/draft-gudlab-agentid-protocol/ > > PROBLEM > ------- > > OAuth solved user-to-app delegation. OpenID Connect solved user > identity federation. But as AI agents increasingly make autonomous > requests to APIs and services, we have no standardised answer to: > > 1. Which agent is making this request? > 2. Who is accountable for it? > 3. What is it permitted to do? > > The result is ad-hoc solutions: raw API keys with no ownership > tracing, OAuth tokens repurposed beyond their design intent, and > proprietary agent authentication schemes that fragment the ecosystem. > > APPROACH > -------- > > AgentID introduces the Agent Identity Token (AIT) - a signed JWT > (ES256) carrying: > > - Agent identity claims (agent_id, name, version) > - Owner accountability claims (owner_id, verification_level 0-3) > - Capability claims (resource:action namespace) > - Delegation chain with scope attenuation > > The protocol defines: > > - Four owner verification levels (email -> domain DNS -> KYB) > - Three service-side access tiers (open/authenticated/permissioned) > - Transparent delegation chains where each hop can only narrow > permissions (scope attenuation) > - A registry API for public key distribution (JWKS), agent lookup, > and real-time revocation > > RELATIONSHIP TO EXISTING WORK > ----------------------------- > > This draft is complementary to: > > - draft-klrc-aiagent-auth-00 (Kasselman et al.) which proposes > applying existing OAuth/WIMSE standards to agent auth. AgentID > focuses specifically on the *identity* layer - giving each agent > a stable, verifiable identity with owner accountability and > delegation provenance. The two drafts address different layers > of the same problem. > > - draft-yl-agent-id-requirements-00 (Yao, Liu) which defines > requirements for AI agent digital identity. AgentID proposes a > concrete protocol meeting many of those requirements. > > - OAuth 2.0 Token Exchange (RFC 8693) which AgentID's delegation > chain references as one evidence mechanism > ("oauth2:token_exchange"). > > AgentID does NOT replace OAuth. It adds agent-to-service identity > as a layer that works alongside OAuth user authorization. A service > can verify "which agent?" (AgentID) independently from "what did the > user allow?" (OAuth). > > KEY DESIGN DECISIONS > -------------------- > > - ES256-only (compact signatures for high-frequency agent traffic) > - Self-contained tokens (offline verification via cached JWKS) > - Max 24h token lifetime (1h recommended) > - jti-based replay prevention > - Owner verification is tiered, not binary > - Delegation chains enforce scope attenuation at each hop > > FEEDBACK REQUESTED > ------------------ > > I would particularly welcome feedback on: > > 1. Whether the AIT claim set is sufficient or over-specified > 2. The delegation chain model vs. alternatives (e.g., nested JWTs, > token exchange chains) > 3. Interaction with WIMSE and existing workload identity work > 4. Whether this belongs as a standalone draft or should be folded > into the broader agent auth effort (draft-klrc) > > The spec, reference implementation, and discussion are also on GitHub: > https://github.com/gudlab/agentid > > Looking forward to the discussion. > > Best, > Tim Uzua > GudLab | gudlab.org > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
