Agent Auth Protocol

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 13 July 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

OAuth was created to replace the anti-pattern of users providing their passwords to applications to scrape their data from web sites. With OAuth, users could authorize an application to scoped access of their data without sharing their passwords. The internet has evolved significantly since the release of OAuth 2.0.¶

Security requirements have changed. Exfiltration of bearer tokens has become a common attack vector. While proof-of-possession with digital signatures is now practical and widely supported, bearer tokens and shared secrets are still used in most deployments.¶

Applications are distributed and more diverse. When OAuth 2.0 was created, the client was typically a server. Today it may also be one of many widely distributed instances of a desktop, mobile, or command line application where managing a single long lived shared secret or private key is impractical.¶

Agents have loosened the client-server model. Tightly bound, pre-registered client and server relationships are giving way to more open and dynamic ecosystems. In environments like the Model Context Protocol (MCP), a client may interact with any server, not just those it was pre-registered with.¶

Enterprise systems span multiple trust domains. Organizations deploy hundreds of applications across vendors, each requiring access to resources in different security contexts. Role-based authorization is often insufficient. Fine-grained, dynamic access control often requires verifying both the calling application and user's identity.¶

OAuth scopes have become insufficient for modern authorization. Traditional OAuth scopes like read or write provide only coarse-grained labels that fail to convey what data will be accessed, under what conditions, for what purpose, or for how long. This opacity prevents meaningful user consent and makes it impossible to enforce least privilege.¶

Resources have varying auth requirements. Resources need different levels of protection for different operations. Public endpoints rely on IP addresses for rate limiting and abuse prevention. Application identity is verified through IP whitelisting, mTLS, or long-lived credentials. Authorization uses API keys, manually provisioned tokens, or OAuth flows. These varying requirements have led to fragmented solutions.¶

Applications require both authentication and authorization. OAuth 2.0 provides authorization (delegated access). OpenID Connect provides authentication (user identity via SSO). Both protocols excel in their designed use cases, but applications often need both authentication and authorization in contexts where the separation creates friction.¶

AAuth is an exploratory specification examining what new capabilities and features may be useful to address use cases that are not well-served by existing protocols like OAuth 2.0, OpenID Connect (OIDC), and SAML.¶

2. Conventions and Definitions

{::boilerplate bcp14-tagged}¶

3. Terminology

Agent

An application or software component acting on behalf of a user or autonomously. In AAuth, agents have cryptographic identity and make signed requests.¶

Agent Server

A server that manages agent identity and issues agent tokens to agent delegates. Identified by an HTTPS URL and publishes metadata at /.well-known/aauth-agent.¶

Agent Delegate

An instance of an agent that holds an agent token and makes requests on behalf of the agent. Each delegate has its own signing key and a unique sub identifier.¶

Agent Token

A JWT issued by an agent server to an agent delegate, binding the delegate's signing key to the agent's identity.¶

Auth Server

A server that authenticates users, obtains consent, and issues auth tokens. Publishes metadata at /.well-known/aauth-issuer.¶

Auth Token

A JWT issued by an auth server that grants an agent access to a resource, containing agent identity, user identity (if applicable), and authorized scopes.¶

Resource

A protected API or service that requires authentication and/or authorization. May publish metadata at /.well-known/aauth-resource.¶

Resource Token

A JWT issued by a resource that binds an access request to the resource's identity, preventing confused deputy attacks.¶

4. Protocol Overview

AAuth uses a three-party model where agents access resources with authorization from auth servers. All requests are signed using HTTP Message Signatures ([RFC9421]).¶

5. Agent-Auth Response Header

Resources use the Agent-Auth response header to indicate authentication requirements when returning 401 Unauthorized.¶

HTTP/1.1 401 Unauthorized
Agent-Auth: httpsig

HTTP/1.1 401 Unauthorized
Agent-Auth: httpsig; identity=?1

HTTP/1.1 401 Unauthorized
Agent-Auth: httpsig; auth-token; resource_token="..."; auth_server="https://auth.example"

6. Agent Tokens

Agent tokens enable agent servers to delegate signing authority to agent delegates while maintaining a stable agent identity.¶

Signature-Key: sig=jwt; jwt="eyJhbGciOiJFZERTQSIsInR5cCI6ImFnZW50K2p3dCJ9..."

7. Resource Tokens

Resource tokens provide cryptographic proof of resource identity, preventing confused deputy and MITM attacks.¶

Agent-Auth: httpsig; auth-token; resource_token="eyJ..."; auth_server="https://auth.example"

8. Auth Tokens

Auth tokens grant agents access to resources after authentication and authorization.¶

Signature-Key: sig=jwt; jwt="eyJhbGciOiJFZERTQSIsInR5cCI6ImF1dGgrand0In0..."

9. Metadata Documents

Participants publish metadata at well-known URLs to enable discovery.¶

{
  "agent": "https://agent.example",
  "jwks_uri": "https://agent.example/.well-known/jwks.json"
}

{
  "issuer": "https://auth.example",
  "agent_token_endpoint": "https://auth.example/token",
  "agent_auth_endpoint": "https://auth.example/authorize",
  "jwks_uri": "https://auth.example/.well-known/jwks.json"
}

{
  "resource": "https://resource.example",
  "jwks_uri": "https://resource.example/.well-known/jwks.json",
  "additional_signature_components": ["content-type", "content-digest"]
}

10. HTTP Message Signing Profile

AAuth uses HTTP Message Signatures ([RFC9421]) for request authentication.¶

11. Error Responses

AAuth uses the OAuth 2.0 error response format ([RFC6749] Section 5.2).¶

{
  "error": "invalid_request",
  "error_description": "Human-readable description"
}

{
  "error": "invalid_signature",
  "error_description": "Signature missing required components",
  "required_components": ["@method", "@authority", "@path", "signature-key"]
}

12. Security Considerations

13. IANA Considerations

Appendix A. Acknowledgments

The author would like to thank reviewers for their feedback on this specification.¶

Author's Address