AAuth Protocol

4.1.1. Agent Identity Access

The agent signs requests with its agent token Section 5.2. The resource verifies the agent's identity via HTTP signatures and applies its own access control policy — granting or denying based on who the agent is. This replaces API keys with cryptographic identity. No authorization flow, no tokens beyond the agent token.¶

Agent                                        Resource
  |                                             |
  | HTTPSig w/ agent_token                      |
  |-------------------------------------------->|
  |                                             |
  | 200 OK                                      |
  |<--------------------------------------------|

4.1.2. Resource-Managed Access (Two-Party)

The resource handles authorization itself — via interaction Section 8.2, existing OAuth/OIDC infrastructure, or internal policy. After authorization, the resource MAY return an AAuth-Access header Section 7.5 with a session token for subsequent calls.¶

Agent                                        Resource
  |                                             |
  | HTTPSig w/ agent_token                      |
  |-------------------------------------------->|
  |                                             |
  | 202 (interaction required)                  |
  |<--------------------------------------------|
  |                                             |
  | [user completes interaction]                |
  |                                             |
  | GET pending URL                             |
  |-------------------------------------------->|
  |                                             |
  | 200 OK                                      |
  | AAuth-Access: session-token                 |
  |<--------------------------------------------|
  |                                             |
  | HTTPSig w/ agent_token                      |
  | Authorization: AAuth session-token          |
  |-------------------------------------------->|
  |                                             |
  | 200 OK                                      |
  |<--------------------------------------------|

4.1.3. Person Identity Access

The agent obtains a person token from its PS for this resource Section 6.1 and signs requests with it in place of its agent token. The resource verifies the token, learns which person the agent acts for — and, when the token carries one, which mission — and applies its own access control on that identity. No resource token, no auth token, and the PS is not in the path of any call.¶

This is federated login for agents. The resource decides what identity alone entitles the person to, exactly as it would after a login it ran itself; the difference is that it did not have to run one.¶

Agent                                        Resource
  |                                             |
  | HTTPSig w/ person_token                     |
  |-------------------------------------------->|
  |                                             |
  | 200 OK                                      |
  |<--------------------------------------------|

A resource that needs more than identity for a particular operation challenges for it there, with requirement=auth-token Section 7.7, while continuing to serve the rest on the person token. Most calls needing only identity and a few sensitive operations needing an authorization decision is the expected shape.¶

4.1.4. PS Authorization Access (Three-Party)

The resource has no separate access server — it accepts identity claims from whichever PS the agent declares, and applies its own policy on the resulting claims. The ps claim in the agent token tells the resource that the agent has a person server and which one, which is how the resource knows to challenge for a person token at all. The PS the resource then acts on is the iss of the person token it verifies Section 6; the resource copies that value into the ps claim of the resource token Section 7 it issues with aud = PS URL. The agent obtains the resource token either by calling the resource's authorization_endpoint (if published in resource metadata) or by receiving a 401 challenge with requirement=auth-token when calling the resource directly Section 7.7. The agent sends the resource token to the PS's token endpoint Section 8.1, and the PS returns an auth token Section 10.4 asserting identity claims about the user (sub, optionally email, tenant, groups, roles) and confirming user consent for the scope the resource requested. The resource applies its own access policy on the resulting claims. Any agent's PS can assert identity claims to any resource without bilateral setup; the resource namespaces those claims by the asserting PS — the same sub value from a different PS is a different subject. As in many OIDC deployments, registration and login share a single flow (see Section 15.9 for how the resource matches or creates a user record from (iss, sub)).¶

Agent                                 Resource       PS
  |                                      |            |
  | HTTPSig w/ agent_token               |            |
  | POST authorization_endpoint          |            |
  |------------------------------------->|            |
  |                                      |            |
  | resource_token (aud = PS URL)        |            |
  |<-------------------------------------|            |
  |                                      |            |
  | HTTPSig w/ agent_token               |            |
  | POST auth_token_endpoint             |            |
  | w/ resource_token                    |            |
  |-------------------------------------------------->|
  |                                      |            |
  | auth_token                           |            |
  |<--------------------------------------------------|
  |                                      |            |
  | HTTPSig w/ auth_token                |            |
  | GET /api/documents                   |            |
  |------------------------------------->|            |
  |                                      |            |
  | 200 OK                               |            |
  |<-------------------------------------|            |

4.1.5. Federated Authorization Access (Four-Party)

The resource has its own access server. The resource issues a resource token Section 7 with aud = AS URL — either via its authorization_endpoint or a 401 challenge Section 7.7. The PS federates with the AS Section 10.3 to obtain the auth token Section 10.4.¶

Agent                                Resource   PS                    AS
  |                                     |       |                      |
  | HTTPSig w/ agent_token              |       |                      |
  | POST authorization_endpoint         |       |                      |
  |------------------------------------>|       |                      |
  |                                     |       |                      |
  | resource_token (aud = AS URL)       |       |                      |
  |<------------------------------------|       |                      |
  |                                     |       |                      |
  | HTTPSig w/ agent_token              |       |                      |
  | POST auth_token_endpoint            |       |                      |
  | w/ resource_token                   |       |                      |
  |-------------------------------------------->|                      |
  |                                     |       |                      |
  |                                     |       | HTTPSig w/ jwks_uri  |
  |                                     |       | POST                 |
  |                                     |       | auth_token_endpoint  |
  |                                     |       | w/ resource_token    |
  |                                     |       |--------------------->|
  |                                     |       |                      |
  |                                     |       | auth_token           |
  |                                     |       |<---------------------|
  |                                     |       |                      |
  | auth_token                          |       |                      |
  |<--------------------------------------------|                      |
  |                                     |       |                      |
  | HTTPSig w/ auth_token               |       |                      |
  | GET /api/documents                  |       |                      |
  |------------------------------------>|       |                      |
  |                                     |       |                      |
  | 200 OK                              |       |                      |
  |<------------------------------------|       |                      |

4.4.1. Missions

When the person's PS requires governance over the agent's actions, the agent creates a mission — a Markdown description of what it intends to accomplish. The PS and user review, clarify, and approve the mission. The approved mission is immutable — bound by its s256 hash. Missions evolve through the mission log Section 9.3: the ordered record of all agent↔PS interactions within the mission. Missions are not required for all PS interactions — an agent can get auth tokens without a mission. See Section 9 for normative requirements.¶

Agent                                     PS                        User
  |                                        |                          |
  | HTTPSig w/ agent_token                 |                          |
  | POST mission_endpoint                  |                          |
  | proposal                               |                          |
  |--------------------------------------->|                          |
  |                                        |                          |
  | [clarification chat]                   | review, clarify, approve |
  |<-------------------------------------->|<------------------------>|
  |                                        |                          |
  | 200 OK                                 |                          |
  | {s256, mission, person_tokens}         |                          |
  |<---------------------------------------|                          |

Agent                                        Resource
  |                                             |
  | HTTPSig w/ person_token (mission_s256)      |
  | POST authorization_endpoint                 |
  |-------------------------------------------->|
  |                                             |
  | resource_token                              |
  | (mission_s256 included)                     |
  |<--------------------------------------------|

Agent                                     PS                        User
  |                                        |                          |
  | HTTPSig w/ agent_token                 |                          |
  | POST mission_endpoint/{s256}           |                          |
  | action=completion, summary             |                          |
  |--------------------------------------->|                          |
  |                                        |                          |
  |                                        | present summary          |
  |                                        |------------------------->|
  |                                        |                          |
  |                                        | accept / follow-up       |
  |                                        |<-------------------------|
  |                                        |                          |
  | 200 OK (terminated)                    |                          |
  | or clarification (continues)           |                          |
  |<---------------------------------------|                          |

4.4.2. PS Governance Endpoints

The PS provides three governance endpoints. The permission Section 8.4 and interaction Section 8.6 endpoints work with or without a mission. The audit endpoint Section 8.5 requires a mission.¶

• Permission endpoint: Request permission for actions not governed by a remote resource — tool calls, file writes, sending messages.¶
• Audit endpoint: Log actions performed, providing the PS with a complete record for the mission log.¶
• Interaction endpoint: Reach the user through the PS — relay interactions, ask questions, forward payment approvals, or propose mission completion.¶

5.2.1. Agent Token Acquisition

An agent MUST obtain an agent token from its agent provider before participating in the AAuth protocol. The acquisition process follows these steps:¶

1. The agent generates a signing key pair (Ed25519 is RECOMMENDED).¶
2. The agent proves its identity to the agent provider through a platform-specific mechanism.¶
3. The agent provider verifies the agent's identity and issues an agent token binding the agent's public key to the agent's identifier.¶

The mechanism for proving identity is platform-dependent. See [I-D.hardt-aauth-bootstrap] for common patterns including self-hosted agents, browser-based applications, and mobile applications.¶

5.2.2. Agent Token Structure

An agent token is a JWT with typ: aa-agent+jwt containing:¶

Header: - alg: Signing algorithm. A fully-specified identifier is REQUIRED; Ed25519 is RECOMMENDED. Implementations MUST NOT accept none, the polymorphic EdDSA identifier, or any symmetric algorithm Section 13.8.1. - typ: aa-agent+jwt - kid: Key identifier¶

Required payload claims: - iss: Agent provider URL - dwk: aauth-agent.json — the well-known metadata document name for key discovery ([I-D.hardt-httpbis-signature-key]) - sub: Agent identifier (stable across key rotations) - jti: Unique token identifier for replay detection, audit, and revocation - cnf: Confirmation claim ([RFC7800]) with jwk containing the agent's public key. The JWK MUST carry a fully-specified alg member Section 13.8.1. - iat: Issued at timestamp - exp: Expiration timestamp. Agent tokens SHOULD NOT have a lifetime exceeding 24 hours.¶

Optional payload claims: - ps: The HTTPS URL of the agent's person server. Configured per agent instance. When present, it tells a resource that the agent has a person server and which one, before the resource has verified a person token — enough to decide whether to challenge for one. The PS of an issued authorization is the iss of the person token the resource verified Section 6.2, not this claim. This claim is distinct from iss (which identifies the agent provider that issued the token). - parent_agent: Sub-agent marker Section 11.2. When present, the agent is a sub-agent and the value is the identifier of its parent agent. A sub-agent MUST NOT request authorization directly; its parent obtains auth tokens on its behalf Section 11.2.¶

Agent providers MAY include additional claims in the agent token. Companion specifications may define additional claims for use by PSes or ASes in policy evaluation — for example, software attestation, platform integrity, secure enclave status, workload identity assertions, or software publisher identity. PSes and ASes MUST ignore unrecognized claims.¶

5.2.3. Agent Token Usage

Agents present agent tokens via the Signature-Key header ([I-D.hardt-httpbis-signature-key]) using scheme=jwt:¶

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

5.2.4. Agent Token Verification

Verify the agent token per [RFC7515] and [RFC7519]:¶

1. Decode the JWT header. Verify typ is aa-agent+jwt.¶
2. Verify dwk is aauth-agent.json. Discover the issuer's JWKS via {iss}/.well-known/{dwk} per the HTTP Signature Keys specification ([I-D.hardt-httpbis-signature-key]). Locate the key matching the JWT header kid and verify the JWT signature.¶
3. Verify exp is in the future and iat is not in the future.¶
4. Verify iss is a valid HTTPS URL conforming to the Server Identifier requirements.¶
5. Verify cnf.jwk matches the key used to sign the HTTP request.¶
6. If ps is present, verify it is a valid HTTPS URL conforming to the Server Identifier requirements.¶
7. If parent_agent is present, verify it is a valid agent identifier — the parent agent. Its presence marks this as a sub-agent's token Section 11.2; the PS additionally enforces the single-level rule Section 11.2 when such a token signs a request.¶

7.2.1. Response without Resource Token

The resource handles authorization itself. It evaluates the request and returns a deferred response if user interaction is needed:¶

HTTP/1.1 202 Accepted
Location: https://resource.example/authorize/pending/abc123
Retry-After: 0
Cache-Control: no-store
AAuth-Requirement: requirement=interaction;
    url="https://resource.example/interaction"; code="A1B2-C3D4"
Content-Type: application/json

{
  "status": "pending"
}

The user completes interaction at the resource's own consent page. The agent polls the Location URL. When authorization is complete, the resource returns 200 OK and MAY include an AAuth-Access header Section 7.5 containing a session token for subsequent calls.¶

HTTP/1.1 200 OK
AAuth-Access: wrapped-session-token-value
Content-Type: application/json

{
  "status": "authorized",
  "scope": "data.read data.write"
}

If the resource can authorize immediately (e.g., the agent's key is already authorized), it returns 200 OK directly with the optional AAuth-Access header.¶

7.2.2. Response with Resource Token

Alternatively, the resource MAY return a resource token. The resource sets the aud claim based on its configuration:¶

• If the resource has its own AS: aud = AS URL (four-party)¶
• If the resource has no AS but the agent has a PS (ps claim): aud = PS URL (three-party)¶

When the person token carries mission_s256, the resource copies it into the resource token.¶

{
  "resource_token": "eyJhbGc..."
}

The agent sends the resource token to its PS's token endpoint.¶

7.2.3. Authorization Endpoint Error Responses

Error responses use the error response format Section 13.6.2.¶

7.7.1. Deferred Delivery

A resource MAY instead deliver the same requirement as a 202 Accepted deferred response Section 13.5, holding the invocation rather than requiring the agent to retry it:¶

HTTP/1.1 202 Accepted
Location: /pending/f7a3b9c
Retry-After: 5
Cache-Control: no-store
AAuth-Requirement: requirement=auth-token; resource-token="eyJ..."

{
  "status": "pending"
}

The agent verifies the resource token and obtains an auth token exactly as in the 401 case, then completes at the pending URL: it polls with signed GET requests per Section 13.5, presenting the auth token via Signature-Key once it holds one. The resource executes the held invocation on the first poll that presents a valid auth token, and answers with the invocation's response.¶

Completion consumes the pending record. The resource MUST retain the record, with the invocation's result, at least until the auth token's exp, and MUST answer a repeated presentation of the same auth token at the pending URL from that result rather than executing again — a response can be lost in transit, and the agent cannot otherwise distinguish "not executed" from "executed, response lost". If the resource token expires before the agent obtains an auth token, the resource MAY include a fresh resource token in the AAuth-Requirement header of a subsequent poll response; it still holds the invocation, so nothing is re-sent.¶

Which delivery to use is the resource's choice, per invocation. The 401 is the baseline every resource can implement without holding state, and the only delivery that maps onto transports with no place to complete at a separate URL. The 202 suits a resource that can hold the invocation; a resource hosting its own interaction already returns this shape Section 8.6.2. Agents MUST support both: the deferred-response handling agents already implement Section 13.5 applies unchanged, with requirement=auth-token in the pending response rather than requirement=interaction.¶

7.8.1. Resource Token Structure

A resource token is a JWT with typ: aa-resource+jwt containing:¶

Header: - alg: Signing algorithm. A fully-specified identifier is REQUIRED; Ed25519 is RECOMMENDED. Implementations MUST NOT accept none, the polymorphic EdDSA identifier, or any symmetric algorithm Section 13.8.1. - typ: aa-resource+jwt - kid: Key identifier¶

Payload: - iss: Resource URL - dwk: aauth-resource.json — the well-known metadata document name for key discovery ([I-D.hardt-httpbis-signature-key]) - aud: Token audience — the PS URL (when the resource delegates authorization to the agent's PS) or the AS URL (when the resource has its own access server) - jti: Unique token identifier for replay detection, audit, and revocation - ps: The iss of the person token the resource verified — the person server whose namespace sub belongs to - sub: The sub of that person token, identifying the person this authorization is for - presented_jti: The jti of the person token whose verification established ps and sub. On the first challenge of a grant that token was presented with the request; on a step-up or per-call challenge the request carries an auth token, and the resource supplies the value from its record of the person token it verified earlier. Binding the resource token to one person token by jti is what makes mission stripping detectable Appendix B.1.11 - agent_jkt: JWK Thumbprint ([RFC7638]) of the agent's current signing key - iat: Issued at timestamp - exp: Expiration timestamp - scope: Requested scopes, as a space-separated string of scope values. Companion specifications MAY define alternative authorization claims that replace scope.¶

A resource token carries no agent identifier. agent_jkt binds it to the agent's key, and the recipient learns the agent's identity from the agent token that signs the token request.¶

Optional payload claims: - account: The account the authorization is for, echoing the account parameter of the request that produced this token Section 13.3. - mission_s256: REQUIRED when the person token carried one, copied unchanged Section 6.2. A resource MUST NOT omit it. - tenant: Copied from the person token when it carried one. - interaction: Present when the resource requires its own user-facing flow — for example, obtaining OAuth authorization from a third-party service — before the PS can issue an auth token. Contains: - url: HTTPS URL of the resource's interaction endpoint - code: Interaction code to present at that URL¶

Resource tokens SHOULD NOT have a lifetime exceeding 5 minutes, and when mission_s256 is present MUST NOT expire later than that mission's expires_at Section 9.2. The jti claim provides an audit trail for token requests; ASes are not required to enforce replay detection on resource tokens. If a resource token expires before the PS presents it to the AS (e.g., because user interaction was required), the agent MUST obtain a fresh resource token from the resource and submit a new token request to the PS. The PS SHOULD remember prior consent decisions within a mission so the user is not re-prompted when the agent resubmits a request for the same resource and scope.¶

7.8.2. Resource Token Verification

Verify the resource token per [RFC7515] and [RFC7519]:¶

1. Decode the JWT header. Verify typ is aa-resource+jwt.¶
2. Verify dwk is aauth-resource.json. Discover the issuer's JWKS via {iss}/.well-known/{dwk} per the HTTP Signature Keys specification ([I-D.hardt-httpbis-signature-key]). Locate the key matching the JWT header kid and verify the JWT signature.¶
3. Verify exp is in the future and iat is not in the future.¶
4. Verify aud matches the recipient's own identifier (the PS in three-party, or the AS in four-party).¶
5. Verify agent_jkt matches the JWK Thumbprint of the key used to sign the HTTP request.¶
6. A PS MUST resolve presented_jti against its retained records of issued person tokens Section 6.1. If no record exists — a tampered token, another PS's jti, or a token outside the retention window — the PS MUST reject the resource token with unknown_person_token. If a record exists, the PS MUST verify that ps, sub, mission_s256, and tenant match it exactly, rejecting the resource token on any mismatch or omission; a mismatch against an existing record is evidence of tampering, such as mission stripping, and SHOULD be surfaced to operators rather than only rejected. An AS MUST verify that ps names the PS that sent the token request.¶
7. If mission_s256 is present, a PS MUST verify the mission is active and that the current time precedes its expires_at where one is set.¶

For a parent-mediated sub-agent authorization (a subagent_token is present, see Section 11.2), step 5 instead verifies agent_jkt against the subagent_token's cnf.jwk — the sub-agent's key — because the parent, not the sub-agent, signs the HTTP request.¶

7.8.3. Resource Challenge Verification

When an agent receives a 401 response with AAuth-Requirement: requirement=auth-token:¶

1. Extract the resource-token parameter.¶
2. Decode and verify the resource token JWT.¶
3. Verify iss matches the resource the agent sent the request to.¶
4. Verify agent_jkt matches the JWK Thumbprint of the agent's signing key.¶
5. Verify ps matches the agent's own person server, and sub the value in the person token the agent presented.¶
6. Verify exp is in the future.¶
7. Send the resource token to the agent's PS's auth token endpoint.¶

8.1.1. Token Endpoint Modes

8.1.2. Concurrent Token Requests

An agent MAY have multiple token requests pending at the PS simultaneously — for example, when a mission requires access to several resources. Each request has its own pending URL and lifecycle. The PS MUST handle concurrent requests independently. Some requests may be resolved without user interaction (e.g., within existing mission scope), while others may require consent. The PS is responsible for managing concurrent user interactions — for example, by batching consent prompts or serializing them.¶

8.1.3. Agent Token Request

The agent MUST make a signed POST to the PS's auth_token_endpoint. The request MUST include an HTTP Sig Section 13.8 and the agent MUST present its agent token via the Signature-Key header using scheme=jwt.¶

Request parameters:¶

• resource_token (REQUIRED): The resource token.¶
• upstream_token (OPTIONAL): An auth token from an upstream authorization, used in call chaining Section 11.1.1.¶
• subagent_token (OPTIONAL): A sub-agent's agent token, present when a parent agent requests authorization on behalf of one of its sub-agents Section 11.2. The signing agent (the parent) MUST be named by the subagent_token's parent_agent.¶
• justification (OPTIONAL): A Markdown string declaring why access is being requested. The PS SHOULD present this value to the user during consent. The PS MUST sanitize the Markdown before rendering to users. The PS MAY log the justification for audit and monitoring purposes. TODO: Define recommended sections.¶
• login_hint (OPTIONAL): Hint about who to authorize, per [OpenID.Core] Section 3.1.2.1.¶
• tenant (OPTIONAL): Tenant identifier, per OpenID Connect Enterprise Extensions 1.0 [OpenID.Enterprise].¶
• domain_hint (OPTIONAL): Domain hint, per OpenID Connect Enterprise Extensions 1.0 [OpenID.Enterprise].¶
• prompt (OPTIONAL): Space-delimited, case-sensitive list of values specifying whether the PS prompts the user for reauthentication and consent, per [OpenID.Core] Section 3.1.2.1. Defined values: none, login, consent, select_account.¶
• platform (OPTIONAL): Identifier for the runtime platform the agent runs on. The value MUST be from the AAuth Platform Value Registry Section 17.9. Describes the runtime context (where the agent runs) but does not by itself convey what security measures were applied within that context. Used for display at the PS consent screen and the PS's connected-agents dashboard. Agent-attested.¶
• device (OPTIONAL): Short human-readable string identifying the specific device or browser, intended for display so users can distinguish entries in their connected-agents dashboard (e.g., Chrome on macOS, Pixel 8 (App)). The string is opaque to receivers — they display it but do not parse it. The string MUST consist of UTF-8 printable characters only (no control characters) and MUST NOT exceed 64 characters. Agents MUST NOT include personally identifying information beyond what the user has chosen (e.g., user-supplied nicknames). Agent-attested.¶
• capabilities (OPTIONAL): An array of capability values Section 13.1 the agent can handle for this request — the request-body equivalent of the AAuth-Capabilities header, which is not used on PS endpoints. Without a mission, this is how the PS learns the agent's capabilities (for example, whether the agent can drive requirement=interaction). Within a mission, capabilities is OPTIONAL: if omitted, the PS uses the values captured at mission approval Section 9.2; if present, it refreshes them for this request.¶

Example request:¶

POST /token HTTP/1.1
Host: ps.example
Content-Type: application/json
Prefer: wait=45
Signature-Input: sig=("@method" "@authority" "@path"
    "content-type" "content-digest"
    "signature-key");created=1730217600
Signature: sig=:...signature bytes...:
Signature-Key: sig=jwt;jwt="eyJhbGc..."

{
  "resource_token": "eyJhbGc...",
  "justification": "Find available meeting times"
}

8.1.4. PS Response

When the resource token's aud matches the PS's own identifier (three-party), the PS handles user consent for the requested scope and issues an auth token asserting identity and consent — no AS federation is needed. When aud identifies a different server (four-party), the PS federates with the AS per Section 10.3.¶

In both cases, the PS handles user consent if needed and returns one of:¶

Direct grant response (200):¶

{
  "auth_token": "eyJhbGc...",
  "expires_in": 3600
}

User interaction required response (202):¶

HTTP/1.1 202 Accepted
Location: /pending/abc123
Retry-After: 0
Cache-Control: no-store
AAuth-Requirement: requirement=interaction;
    url="https://ps.example/interaction"; code="A1B2-C3D4"
Content-Type: application/json

{
  "status": "pending"
}

In four-party mode, the PS may also pass through a clarification from the AS to the agent via the 202 response Section 10.1.¶

8.1.5. Resource-Initiated Interaction

When the resource token contains an interaction claim, the resource requires its own user-facing flow — typically an OAuth authorization from a third-party service — before authorization can proceed. The PS coordinates this by chaining the resource's flow with its own consent step.¶

The PS resolves the resource interaction before presenting its own consent: if the user declines the resource's underlying authorization, the PS authorization is vacuous, so it makes no sense to ask for PS consent first.¶

Flow:¶

1. The PS returns 202 to the agent with its own interaction URL — the same as for any consent interaction.¶
2. The user arrives at the PS's interaction page. The PS shows an interstitial informing the user that the resource requires additional permissions before the PS can authorize access.¶
3. The PS redirects the user to the resource's interaction endpoint using the standard callback pattern, where ps_callback_url is a PS-generated, per-flow URL: {interaction.url}?code={interaction.code}&callback={ps_callback_url}¶
4. The resource completes its own OAuth or permission flow. The resource MUST redirect the user to the callback URL when its flow completes — either successfully or with an error per Section 8.2.1.¶
5. The PS receives the callback redirect. If the callback contains an error parameter, the PS abandons the authorization and returns the mapped polling error to the agent. Otherwise it continues with its own consent step.¶
6. Upon user approval, the PS issues the auth token and resolves the agent's pending request.¶

A resource's interaction endpoint MUST support the standard ?code=...&callback=... pattern regardless of whether the redirect comes from an agent or from a PS in a chained flow — the endpoint cannot and need not distinguish callers.¶

The interaction.url MUST be an HTTPS URL. The PS MUST validate this before constructing the redirect and MUST apply its egress admission policy to the URL.¶

8.2.1. Interaction Callback Errors

When an interaction cannot be completed successfully, the server MUST redirect to the callback URL with an error query parameter:¶

{callback_url}?error={error_code}

Recipients of a callback with an error parameter MUST NOT treat the pending request as completable and MUST surface the error to the caller. In the resource-initiated interaction flow Section 8.1.5, the PS maps the received callback error to a polling error returned to the agent: access_denied maps to denied; user_abandoned maps to abandoned; interaction_expired maps to expired; server_error and temporarily_unavailable map to server_error.¶

8.3.1. Clarification Required

A server MUST use requirement=clarification with a 202 Accepted response when it needs the recipient to answer a question before proceeding. The response body MUST include a clarification field containing the question and MAY include timeout and options fields.¶

HTTP/1.1 202 Accepted
Location: /pending/abc123
Retry-After: 0
Cache-Control: no-store
AAuth-Requirement: requirement=clarification
Content-Type: application/json

{
  "status": "pending",
  "clarification": "Why do you need write access to my calendar?",
  "timeout": 120
}

Body fields:¶

• clarification (REQUIRED): A Markdown string containing the question.¶
• timeout (OPTIONAL): Seconds until the server times out the request. The recipient MUST respond before this deadline.¶
• options (OPTIONAL): An array of string values when the question has discrete choices.¶

The recipient MUST respond with one of the actions defined in Section 8.3.2: a clarification response, an updated request, or a cancellation. This requirement is used by both PSes (delivering user questions to agents) and ASes (requesting clarification from PSes).¶

8.3.2. Agent Response to Clarification

The agent MUST respond to a clarification with one of:¶

1. Clarification response: POST an action of clarification_response to the pending URL.¶
2. Updated request: POST an action of updated_request with a new resource_token to the pending URL, replacing the original request with updated scope or parameters.¶
3. Cancel request: DELETE the pending URL to withdraw the request.¶

A POST body MUST include an action member identifying the response type. A server MUST reject a POST with a missing or unrecognized action value with 400 Bad Request. The action member makes each POST self-describing and keeps the pending route extensible for future response types.¶

POST /pending/abc123 HTTP/1.1
Host: ps.example
Content-Type: application/json
Content-Digest: sha-256=:...:
Signature-Input: sig=("@method" "@authority" "@path"
    "content-type" "content-digest"
    "signature-key");created=1730217600
Signature: sig=:...signature bytes...:
Signature-Key: sig=jwt;jwt="eyJhbGc..."

{
  "action": "clarification_response",
  "clarification_response":
    "I need to create a meeting invite
     for the participants you listed."
}

POST /pending/abc123 HTTP/1.1
Host: ps.example
Content-Type: application/json
Content-Digest: sha-256=:...:
Signature-Input: sig=("@method" "@authority" "@path"
    "content-type" "content-digest"
    "signature-key");created=1730217600
Signature: sig=:...signature bytes...:
Signature-Key: sig=jwt;jwt="eyJhbGc..."

{
  "action": "updated_request",
  "resource_token": "eyJ...",
  "justification": "I've reduced my request to read-only access."
}

DELETE /pending/abc123 HTTP/1.1
Host: ps.example
Signature-Input: sig=("@method" "@authority"
    "@path" "signature-key");created=1730217600
Signature: sig=:...signature bytes...:
Signature-Key: sig=jwt;jwt="eyJhbGc..."

8.3.3. Clarification Limits

PSes SHOULD enforce limits on clarification rounds (recommended: 5 rounds maximum). Clarification responses from agents are untrusted input and MUST be sanitized before display to the user.¶

8.4.1. Permission Request

The agent MUST make a signed POST to the PS's permission_endpoint. The request MUST include an HTTP Sig Section 13.8 and the agent MUST present its agent token via the Signature-Key header.¶

Request parameters:¶

• action (REQUIRED): A string identifying the action the agent wants to perform (e.g., a tool name).¶
• description (OPTIONAL): A Markdown string describing what the action will do and why.¶
• parameters (OPTIONAL): A JSON object containing the parameters the agent intends to pass to the action.¶
• mission_s256 (OPTIONAL): The mission this request belongs to. When present, the PS evaluates the request against the mission context and log history.¶

POST /permission HTTP/1.1
Host: ps.example
Content-Type: application/json
Content-Digest: sha-256=:...:
Signature-Input: sig=("@method" "@authority" "@path"
    "content-type" "content-digest"
    "signature-key");created=1730217600
Signature: sig=:...signature bytes...:
Signature-Key: sig=jwt;jwt="eyJhbGc..."

{
  "action": "SendEmail",
  "description": "Send the proposed itinerary to the user",
  "parameters": {
    "to": "user@example.com",
    "subject": "Japan trip itinerary"
  },
  "mission_s256": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
}

8.4.2. Permission Response

If the PS can decide immediately, it returns 200 OK:¶

HTTP/1.1 200 OK
Content-Type: application/json

{
  "permission": "granted"
}

The permission field is one of:¶

• granted: The agent MAY proceed with the action.¶
• denied: The agent MUST NOT proceed. The response MAY include a reason field with a Markdown string explaining why.¶

If the mission is no longer active, the PS returns a mission status error Section 9.8.¶

If the PS requires user input, it returns a deferred response Section 13.5 using the same pattern as other AAuth endpoints. The agent polls until the PS returns a final response.¶

The PS SHOULD record all permission requests and responses. When a mission is present, the PS records the permission request and response in the mission log.¶

8.5.1. Audit Request

The agent MUST make a signed POST to the PS's audit_endpoint. The request MUST include an HTTP Sig Section 13.8 and the agent MUST present its agent token via the Signature-Key header.¶

Request parameters:¶

• mission_s256 (REQUIRED): The mission this record belongs to.¶
• action (REQUIRED): A string identifying the action that was performed.¶
• description (OPTIONAL): A Markdown string describing what was done and the outcome.¶
• parameters (OPTIONAL): A JSON object containing the parameters that were used.¶
• result (OPTIONAL): A JSON object containing the result or outcome of the action.¶

POST /audit HTTP/1.1
Host: ps.example
Content-Type: application/json
Content-Digest: sha-256=:...:
Signature-Input: sig=("@method" "@authority" "@path"
    "content-type" "content-digest"
    "signature-key");created=1730217600
Signature: sig=:...signature bytes...:
Signature-Key: sig=jwt;jwt="eyJhbGc..."

{
  "mission_s256": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk",
  "action": "WebSearch",
  "description": "Searched for flights to Tokyo in May",
  "parameters": {
    "query": "flights to Tokyo May 2026"
  },
  "result": {
    "status": "completed",
    "summary": "Found 12 flight options"
  }
}

8.5.2. Audit Response

The PS returns 201 Created to acknowledge the record:¶

HTTP/1.1 201 Created

The audit endpoint is fire-and-forget — the agent SHOULD NOT block on the response. The PS records the audit entry in the mission log. The PS MAY use audit records to detect anomalous behavior, alert the user, or revoke the mission.¶

If the mission is no longer active, the PS returns a mission status error Section 9.8.¶

8.6.1. Interaction Request

The agent MUST make a signed POST to the PS's interaction_endpoint. The request MUST include an HTTP Sig Section 13.8 and the agent MUST present its agent token via the Signature-Key header.¶

Request parameters:¶

• type (REQUIRED): The type of interaction. One of interaction, payment, or question.¶
• description (OPTIONAL): A Markdown string providing context for the user.¶
• url (OPTIONAL): The interaction URL to relay to the user (for interaction and payment types).¶
• code (OPTIONAL): The interaction code associated with the URL.¶
• max_wait (OPTIONAL): Maximum seconds the PS SHOULD hold the relay's deferred response before resolving it (for interaction and payment types). When the interaction URL is resource-hosted, the PS resolves its deferred response once the user has engaged or when this window elapses, whichever comes first; the agent then relies on the resource's pending URL for completion Section 8.6.2. Absent max_wait, the PS resolves the relay when the user has engaged or it can make no further progress.¶
• question (OPTIONAL): A Markdown string containing a question for the user (for question type).¶
• mission_s256 (OPTIONAL): The mission this request belongs to.¶

Relay interaction example:¶

POST /interaction HTTP/1.1
Host: ps.example
Content-Type: application/json
Content-Digest: sha-256=:...:
Signature-Input: sig=("@method" "@authority" "@path"
    "content-type" "content-digest"
    "signature-key");created=1730217600
Signature: sig=:...signature bytes...:
Signature-Key: sig=jwt;jwt="eyJhbGc..."

{
  "type": "interaction",
  "description": "The booking service needs you to confirm payment",
  "url": "https://booking.example/confirm",
  "code": "X7K2-M9P4",
  "mission_s256": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
}

8.6.2. Interaction Response

For interaction and payment types, the PS relays the interaction to the user and returns a deferred response Section 13.5.¶

When the interaction URL is hosted by the PS itself, the PS's deferred response is authoritative for completion: the agent polls it until the user completes the interaction.¶

When the interaction URL is hosted by a resource — the common case for a relayed interaction, such as a proxy's OAuth bootstrap page or a merchant's payment-confirmation page — the user completes the interaction at the resource, not at the PS. The agent then holds two pending URLs: the resource's original Location (from the resource's 202) and the PS's relay Location. The resource's pending URL is authoritative for completion. The PS's relay deferred response reports only that the relay reached the user: it returns status: "interacting" Section 13.5 once the user has engaged, and a terminal response when the PS has done all it can — the user engaged, the agent's max_wait window elapsed, or the PS can make no further progress. The agent MUST treat the resource's pending URL as the signal that the interaction is complete, and continues polling it after the PS relay resolves.¶

If the PS has no channel available to relay an interaction or payment to the user, it returns interaction_unavailable Section 8.6.3. This is the PS declining to relay this specific interaction; the agent falls back to directing the user to the url/code itself Section 13.4.3.2. It is distinct from user_unreachable: interaction_unavailable is non-terminal — the agent can still drive the interaction — whereas user_unreachable Section 13.6.3 is terminal, meaning no party can reach the user.¶

For question type, the PS delivers the question to the user and returns the answer:¶

HTTP/1.1 200 OK
Content-Type: application/json

{
  "answer": "Yes, go ahead with the refundable option."
}

If the PS cannot reach the user and the agent does not have the interaction capability, the PS returns user_unreachable Section 13.6.3 — a terminal error, since no party can reach the user. If the mission is no longer active, the PS returns a mission status error Section 9.8. The PS SHOULD record all interaction requests and responses. When a mission is active, the PS records the interaction in the mission log.¶

8.6.3. Interaction Endpoint Errors

Errors use the error response format Section 13.6.2.¶

9.2.1. Mission Identifier

s256 identifies the mission everywhere it appears — as the mission_s256 claim of person, resource, and auth tokens, and as the mission_s256 parameter of PS requests.¶

It is a hash rather than an opaque identifier so that it is provable. An opaque identifier would name the mission but leave the PS free to attach it to any text afterwards. A digest binds every token carrying mission_s256 to one specific mission, so the mission in the PS's log and the mission those tokens authorized are demonstrably the same.¶

The PS MUST compute s256 over the exact bytes it persists as the mission blob, MUST return those same bytes as mission, and MUST serve them wherever it later exposes the mission for audit.¶

The approved description MAY differ from the proposal — the PS or user may refine, constrain, or expand the mission during review. The approved tools MAY be a subset of the proposed tools. The agent uses s256 as mission_s256 when requesting further person tokens Section 6.1.¶

10.1.1. PS-to-AS Token Request

The PS MUST make a signed POST to the AS's auth_token_endpoint. The PS authenticates via an HTTP Sig Section 13.8.¶

Request parameters:¶

• resource_token (REQUIRED): The resource token issued by the resource.¶
• agent_token (REQUIRED): The agent's agent token. For a parent-mediated sub-agent authorization, this is the parent (top-level) agent's token.¶
• subagent_token (OPTIONAL): A sub-agent's agent token, present when the PS federates a parent-mediated sub-agent authorization Section 11.2. When present, the AS binds the issued auth token to the sub-agent, verifying resource_token's agent_jkt against the subagent_token's cnf.jwk.¶
• upstream_token (OPTIONAL): An auth token from an upstream authorization, used in call chaining Section 11.1.1.¶

The resource token carries the person's identity as ps and sub Section 7.8.1, so the AS needs no separate identity parameter and requirement=claims Section 10.2 is reserved for claims beyond it.¶

agent_token remains REQUIRED even though the resource never sees an agent identifier. A resource deploys an AS because it wants policy evaluated, and an agent token MAY carry claims bearing on that decision — software attestation, platform integrity, secure enclave status, workload identity Section 5.2.2. The resource enforces; the AS evaluates; posture goes to the evaluator.¶

Example request:¶

POST /token HTTP/1.1
Host: as.resource.example
Content-Type: application/json
Signature-Input: sig=("@method" "@authority"
    "@path" "signature-key");created=1730217600
Signature: sig=:...signature bytes...:
Signature-Key: sig=jwks_uri;
    jwks_uri="https://ps.example/.well-known/jwks.json"

{
  "resource_token": "eyJhbGc...",
  "agent_token": "eyJhbGc..."
}

10.1.2. AS Response

The PS calls the AS token endpoint and follows the standard deferred response loop Section 13.5: it handles 202 and 402 responses and continues until it receives a 200 with an auth token or a terminal error.¶

Direct grant response (200):¶

{
  "auth_token": "eyJhbGc...",
  "expires_in": 3600
}

The AS MAY return 202 Accepted with an AAuth-Requirement header indicating what is needed before it can issue an auth token:¶

• requirement=claims Section 10.2: The AS needs identity claims. The body includes required_claims. The PS MUST provide the requested claims (including a directed sub identifier for the resource) by POSTing to the Location URL. The AS cannot know what claims it needs until it has processed the resource token.¶
• requirement=clarification Section 8.3.1: The AS needs a question answered. The PS triages who answers: itself (if mission context has the answer), the user, or the agent. The PS MAY pass the clarification down to the agent via a 202 response.¶
• requirement=interaction Section 13.4: The AS requires user interaction — for example, the user must authenticate at the AS to bind their PS, or the resource owner must approve access. The PS directs the user to the AS's interaction URL, or passes the interaction requirement back to the agent.¶
• requirement=approval Section 13.4: The AS is obtaining approval without requiring user direction.¶

Payment required (402):¶

The AS MAY return 402 Payment Required when a billing relationship is required before it will issue auth tokens. The 402 response includes payment details per an applicable payment protocol such as x402 [x402] or the Machine Payment Protocol (MPP) ([I-D.ryan-httpauth-payment]). The response MUST include a Location header for the PS to poll after payment is settled.¶

HTTP/1.1 402 Payment Required
Location: https://as.resource.example/token/pending/xyz
WWW-Authenticate: Payment id="x7Tg2pLq", method="stripe",
    request="eyJhbW91bnQiOiIxMDAw..."

The PS settles payment per the indicated protocol and polls the Location URL. When payment is confirmed, the AS continues processing the token request — which may result in a 200 with an auth token, or a further 202 requiring claims, interaction, or approval.¶

The PS caches the billing relationship per AS. Future token requests from the same PS to the same AS skip the billing step. The payment protocol, settlement mechanism, and billing terms are out of scope for this specification.¶

10.1.3. Auth Token Delivery

When the AS issues an auth token (200 response), the PS MUST verify the auth token before returning it to the agent:¶

1. Verify the auth token JWT signature using the AS's JWKS Section 13.9.¶
2. Verify iss matches the AS the PS sent the token request to.¶
3. Verify aud matches the resource identified by the resource token's iss.¶
4. Verify cnf.jwk matches the agent's signing key.¶
5. Verify sub matches the directed identifier the PS issues for this person at this resource.¶
6. Verify scope is consistent with what was requested — not broader than the scope in the resource token.¶

After verification, the PS returns the auth token to the agent. The agent presents the auth token to the resource via the Signature-Key header Section 10.4.2. The resource verifies the auth token against the AS's JWKS Section 10.4.3.¶

The agent receives the auth token from its trusted PS, so signature verification is not strictly required. However, agents SHOULD verify the auth token's signature to detect errors early. Agents MUST verify that aud and cnf match their own values.¶

10.3.1. PS-AS Trust Establishment

Trust between the PS and AS may be pre-established out of band or emerge dynamically from the AS's response to the PS's first token request — AAuth does not require a separate registration step before the protocol can be used. The AS evaluates the token request and responds based on its current policy:¶

• Pre-established: A business relationship configured between the PS and AS, potentially including payment terms, SLA, and compliance requirements. The AS recognizes the PS and processes the token request directly.¶
• Interaction: The AS returns 202 with requirement=interaction, directing the user to authenticate at the AS and confirm their PS. After this one-time binding, the AS trusts future requests from that PS for that user. This is the primary mechanism for establishing trust dynamically.¶
• Payment: The AS returns 402, requiring the PS to establish a billing relationship before tokens will be issued. The PS settles payment per the indicated protocol and polls for completion. After billing is established, the AS trusts future requests from that PS.¶
• Claims only: The AS may trust any PS that can provide sufficient identity claims for a policy decision, without requiring a prior relationship.¶

These mechanisms may compose: for example, the AS may first require payment (402), then interaction for user binding (202), then claims (202) before issuing an auth token. Each step uses the same Location URL for polling.¶

PS                        User                    AS
  |                         |                       |
  |  POST /token            |                       |
  |  resource_token,        |                       |
  |  agent_token            |                       |
  |------------------------------------------------>|
  |                         |                       |
  |  402 Payment Required   |                       |
  |  Location: /token/pending/xyz                   |
  |<------------------------------------------------|
  |                         |                       |
  |  [PS settles payment per indicated protocol]    |
  |                         |                       |
  |  GET /token/pending/xyz |                       |
  |------------------------------------------------>|
  |                         |                       |
  |  202 Accepted           |                       |
  |  requirement=interaction|                       |
  |  url=".../authorize/abc"|                       |
  |<------------------------------------------------|
  |                         |                       |
  |  direct user to URL     |                       |
  |------------------------>|                       |
  |                         |  authenticate, bind PS|
  |                         |---------------------->|
  |                         |                       |
  |  GET /token/pending/xyz |                       |
  |------------------------------------------------>|
  |                         |                       |
  |  202 Accepted           |                       |
  |  requirement=claims     |                       |
  |<------------------------------------------------|
  |                         |                       |
  |  POST /token/pending/xyz|                       |
  |  {sub, email, tenant}   |                       |
  |------------------------------------------------>|
  |                         |                       |
  |  200 OK (auth_token)    |                       |
  |<------------------------------------------------|
  |                         |                       |

{: #fig-mm-as-trust title="PS-AS Trust Establishment (all steps shown — most requests skip some)"}¶

10.3.2. AS Decision Logic (Non-Normative)

The following is a non-normative description of how an AS might evaluate a token request:¶

1. PS = AS (same entity): Grant directly. The federation call is internal and trust is implicit. See Section 10.3.4.¶
2. User has bound this PS at the AS: Apply the user's configured policy for this PS.¶
3. PS is pre-established (enterprise agreement): Apply the organization's configured policy.¶
4. Resource is open or has a free tier: Grant with restricted scope or rate limits.¶
5. Resource requires billing: Return 402 with payment details.¶
6. Resource requires user binding: Return 202 with requirement=interaction.¶
7. AS needs identity claims to decide: Return 202 with requirement=claims.¶
8. Insufficient trust for requested scope: Return 403.¶

The AS is not required to follow this order. The decision logic is entirely at the AS's discretion based on resource policy.¶

10.3.3. Organization Visibility

Organizations benefit from the trust model: an organization's agents share a single PS, and internal resources may share a single AS. The PS provides centralized audit across all agents and missions. Federation is only incurred at the boundary, when an internal agent accesses an external resource. When the same server fills both the PS and AS roles, federation collapses to a single internal evaluation — see Section 10.3.4.¶

10.3.4. PS-AS Collapse

When the agent's PS and the resource's chosen AS are the same server (an instance of role collocation, see Section 4.2), federation collapses to a single internal evaluation. This is operationally similar to three-party access — no cross-server hop — but structurally different:¶

• Three-party (PS authorization): the resource has no AS; the resource token's aud is the PS, and the auth token has dwk: aauth-person.json. The resource trusts identity claims and applies its own policy.¶
• PS-AS collapse: the resource has chosen an AS that also operates as the agent's PS; the resource token's aud is the AS, and the auth token has dwk: aauth-access.json. The resource trusts the AS's policy verdict.¶

The server applies user consent (its PS responsibility) and resource policy (its AS responsibility) in a single evaluation. Trust between PS and AS is implicit because they are the same entity.¶

10.4.1. Auth Token Structure

An auth token is a JWT with typ: aa-auth+jwt containing:¶

Header: - alg: Signing algorithm. A fully-specified identifier is REQUIRED; Ed25519 is RECOMMENDED. Implementations MUST NOT accept none, the polymorphic EdDSA identifier, or any symmetric algorithm Section 13.8.1. - typ: aa-auth+jwt - kid: Key identifier¶

Required payload claims: - iss: The URL of the server that issued the auth token — an AS (four-party) or a PS asserting identity (three-party) - dwk: The well-known metadata document name for key discovery ([I-D.hardt-httpbis-signature-key]). aauth-access.json when issued by an AS, aauth-person.json when issued by a PS. - aud: The URL of the resource the agent is authorized to access. - jti: Unique token identifier for replay detection, audit, and revocation - ps: The person server the person is represented by. Equal to iss when a PS issued the token. An intermediary acting as an agent routes its downstream token request here Section 11.1.1. - sub: Directed user identifier, copied from the resource token. An opaque string, unique within iss, that identifies the person. The PS SHOULD derive a pairwise pseudonymous value per resource (aud), so different resources see different values for the same person Section 16.1. - cnf: Confirmation claim with jwk containing the agent's public key. The JWK MUST carry a fully-specified alg member Section 13.8.1. - iat: Issued at timestamp - exp: Expiration timestamp. Auth tokens MUST NOT have a lifetime exceeding 1 hour, and when mission_s256 is present MUST NOT be later than that mission's expires_at Section 9.2.¶

An auth token carries no agent identifier and no delegation chain. cnf binds it to one key, and the resource enforces against sub and scope.¶

Optional payload claims: - scope: Authorized scopes, as a space-separated string of scope values consistent with [RFC9068] Section 2.2.3 - account: The account the authorization is for, copied from the resource token Section 13.3. - mission_s256: Copied from the resource token when it carried one. Present when the auth token was issued in the context of a mission. - tenant: Tenant identifier per OpenID Connect Enterprise Extensions 1.0 [OpenID.Enterprise], declaring the organization the person belongs to. (iss, tenant) identifies the organization. It is not part of the person's identifier, which is (iss, sub).¶

The auth token MAY include additional claims registered in the IANA JSON Web Token Claims Registry [RFC7519] or defined in OpenID Connect Core 1.0 [OpenID.Core] Section 5.1.¶

10.4.2. Auth Token Usage

Agents present auth tokens via the Signature-Key header ([I-D.hardt-httpbis-signature-key]) using scheme=jwt:¶

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

Once an auth token has been issued for a resource, the agent presents the auth token (not the agent token) via Signature-Key on subsequent requests to that resource. The auth token's cnf.jwk is the same key that signed the request, so HTTP Message Signature verification proceeds identically to the agent-token case.¶

10.4.3. Auth Token Verification

When a resource receives an auth token, verify per [RFC7515] and [RFC7519]. A valid JWT signature alone is not a complete AAuth authorization check — both JWT trust and request-context binding must pass.¶

10.4.4. Auth Token Response Verification

When an agent receives an auth token:¶

1. SHOULD verify the auth token JWT signature using the issuer's JWKS (the AS in four-party, or the PS in three-party). The agent trusts its PS, so signature verification is not required but is RECOMMENDED to detect errors early.¶
2. Verify iss matches the resource token's aud claim.¶
3. Verify aud matches the resource the agent intends to access.¶
4. Verify cnf.jwk matches the agent's own signing key.¶
5. Verify sub matches the value in the person token it presented to that resource.¶

10.4.5. Upstream Token Verification

When the PS or AS receives an upstream_token parameter in a call chaining request:¶

1. Perform Auth Token Verification Section 10.4.3 on the upstream token.¶
2. Verify iss is a trusted issuer (a PS or AS whose auth token the recipient previously brokered or is authorized to extend).¶
3. Verify the aud in the upstream token equals the iss of the intermediary's agent token (presented in the Signature-Key header). This binding confirms the upstream token was issued to the resource now making the downstream request.¶
4. The PS evaluates its mission and governance policy based on the upstream token's claims and mission context. The resulting downstream authorization is not required to be a subset of the upstream scopes — see Section 11.1.1.¶

11.1.1. Call Chaining

When a resource needs to access a downstream resource on behalf of the caller, it acts as an agent. It routes the downstream token request to the person server named by the ps claim of the upstream auth token it received. The ps claim in the calling agent's own agent token is NOT used for this routing — that names the intermediary's person server, not the person's.¶

The intermediary first obtains a person token for the downstream resource, presenting the upstream auth token as upstream_token Section 6.1. It then presents that person token at the downstream resource, receives a resource token, and sends it to the person server named by ps, along with its own agent token and the upstream auth token as upstream_token. The PS evaluates the downstream request against the mission context when the upstream token carries mission_s256.¶

In every case the intermediary signs the downstream token request with its own key, presenting its own agent token via the Signature-Key header Section 13.8. The upstream_token is a body parameter — it is neither presented via Signature-Key nor used as the signing key. It is the auth token previously issued to the intermediary (its aud is the intermediary and its cnf is the intermediary's key), and it serves only as proof of the upstream authorization that the recipient extends downstream. The signature the recipient verifies is therefore always the intermediary's, over its own key.¶

The recipient evaluates the downstream request per Section 10.4.5.¶

11.1.2. Interaction Chaining

When the PS or AS requires user interaction for the downstream access, it returns a 202 with requirement=interaction. Resource 1 chains the interaction back to the original agent by returning its own 202.¶

When a resource acting as an agent receives a 202 Accepted response with AAuth-Requirement: requirement=interaction, and the resource needs to propagate this interaction requirement to its caller, it MUST return a 202 Accepted response to the original agent with its own AAuth-Requirement header containing requirement=interaction and its own interaction code. The resource MUST provide its own Location URL for the original agent to poll. When the user completes interaction and the resource obtains the downstream auth token, the resource completes the original request and returns the result at its pending URL.¶

11.2.1. Sub-Agent Identity

A sub-agent has its own agent identity — its own aauth:local@domain identifier and signing key, issued by the agent provider, exactly like a top-level agent. Two things distinguish it:¶

• parent_agent claim: the sub-agent's agent token includes parent_agent set to the parent agent's identifier. Its presence is the authoritative marker of sub-agent status.¶
• Local-part naming: the sub-agent's local part MUST be the parent's local part followed by + and a non-empty discriminator Section 5.1 — for example aauth:planner.7f3c+search1@vendor.example. For protocol decisions, verifiers rely on parent_agent, not on parsing the local part; the naming is for operational readability (e.g., logs).¶

{
  "iss": "https://vendor.example",
  "dwk": "aauth-agent.json",
  "sub": "aauth:planner.7f3c+search1@vendor.example",
  "cnf": { "jwk": { "kty": "OKP", "crv": "Ed25519",
                    "x": "...", "alg": "Ed25519" } },
  "ps":  "https://ps.example",
  "parent_agent": "aauth:planner.7f3c@vendor.example"
}

Acquisition of a sub-agent token from the agent provider is platform-dependent and is described in [I-D.hardt-aauth-bootstrap], parallel to top-level agent token acquisition.¶

11.2.2. Single-Level Depth

Delegation is at most one level deep: a top-level agent may have sub-agents, but a sub-agent MUST NOT have sub-agents of its own. Two rules enforce this:¶

• A PS MUST reject a token request signed by an agent whose agent token has a parent_agent claim — a sub-agent cannot request authorization on its own behalf or on behalf of a further sub-agent.¶
• An agent provider MUST NOT issue a sub-agent token whose parent (parent_agent) is itself a sub-agent.¶

For genuinely deeper workflows, AAuth already provides chained top-level agents Section 11.1.1: each hop is an independent principal with its own grant, rather than recursive sub-agent spawning.¶

11.2.3. Parent-Mediated Authorization

A sub-agent MUST NOT call the PS directly. Instead, the parent obtains auth tokens on the sub-agent's behalf:¶

1. The parent obtains a person token for the sub-agent by POSTing to the PS's person_token_endpoint with subagent_token Section 6.1; the issued token's cnf is the sub-agent's key. It passes the person token to the sub-agent out of band (for example, via IPC).¶
2. The sub-agent presents that person token at the resource and obtains a resource token bound to its own key Section 7, exactly as a top-level agent would. It passes the resource token back to its parent.¶
3. The parent POSTs to the PS's auth_token_endpoint, signing the request with its own key and presenting its own agent token via the Signature-Key header. The request body includes resource_token (the sub-agent's resource token) and subagent_token (the sub-agent's agent token).¶

4. The PS processes this as an authorization request from the parent Section 8.1:¶

   • It verifies the HTTP Message Signature against the parent's cnf.jwk.¶
   • It verifies the subagent_token Section 5.2.4 and that its parent_agent names the parent — the agent that signed the request.¶
   • It verifies the resource_token is bound to the sub-agent's key: agent_jkt matches the subagent_token's cnf.jwk, not the signing key Section 7.8.2.¶
   • It evaluates the parent's grant for the requested scope, exactly as for a direct request from the parent. If the user has already consented, the response is immediate; otherwise consent surfaces for the parent as usual.¶
5. On success the issuer — the PS in three-party, or the AS in four-party — issues an auth token bound to the sub-agent's key (cnf = the sub-agent's jwk). In four-party, the PS federates by passing the parent as agent_token and the sub-agent as subagent_token to the AS Section 10.1, so the AS records the parent authoritatively from those tokens. The parent passes the auth token to the sub-agent, which presents it to the resource signing with its own key.¶

The sub-agent relationship is recorded by the PS, which issued both tokens and holds the parent_agent binding. It does not appear in the tokens the resource sees.¶

Because every sub-agent authorization passes through the parent, the parent retains control — it can refuse, attenuate, or rate-limit — and revocation propagates naturally: revoking the parent's grant causes the next sub-agent authorization to fail, while existing auth tokens expire normally (≤1 hour).¶

13.4.1. AAuth-Requirement Header Structure

The AAuth-Requirement header field is a Dictionary ([RFC8941], Section 3.2). It MUST contain the following member:¶

• requirement: A Token ([RFC8941], Section 3.3.4) indicating the requirement type.¶

Requirement-specific data are conveyed as parameters on the requirement member (for example, resource-token, url, code). Recipients MUST ignore unknown parameters.¶

Example:¶

AAuth-Requirement: requirement=auth-token; resource-token="eyJ..."

13.4.2. Requirement Values

The requirement value is an extension point. This document defines the following values:¶

The agent-token requirement is defined in Section 7.3; the person-token requirement in Section 7.4; the auth-token requirement in Section 7.7; the interaction and approval requirements are defined in this section; clarification in Section 8.3.1; and claims in Section 10.2.¶

An agent that does not recognize the requirement value MUST NOT treat the response as satisfiable. It surfaces the unsupported requirement to the caller as an error. For a 202 response with an unrecognized requirement, the agent MAY continue polling the Location URL in case a later response carries a requirement value it does understand, rather than immediately abandoning the request.¶

13.4.3. Interaction Required

When a server requires user action — such as authentication, consent, payment approval, or any decision requiring a human in the loop — it returns a 202 Accepted response:¶

HTTP/1.1 202 Accepted
AAuth-Requirement:
    requirement=interaction;
    url="https://example.com/interact";
    code="A1B2-C3D4"
Location: /pending/f7a3b9c
Retry-After: 0

The AAuth-Requirement header MUST include the following parameters:¶

• url (String): The interaction URL where the user completes the required action. MUST use the https scheme and MUST NOT contain query or fragment components.¶
• code (String): An interaction code that links the agent's pending request to the user's session at the interaction URL. Generated and compared per Section 13.4.3.1.¶

The response MUST also include:¶

• Location: A URL the agent polls (with GET) for a terminal response.¶
• Retry-After: Recommended polling interval in seconds.¶

Agent                        User                         Server
  |                            |                             |
  |  202 Accepted                                            |
  |  AAuth-Requirement:                                      |
  |    requirement=interaction;                              |
  |    url="..."; code="..."                                 |
  |  Location: /pending/...                                  |
  |<---------------------------------------------------------|
  |                            |                             |
  |  open {url}?code={code}    |                             |
  |  (or display code / QR)    |                             |
  |--------------------------->|                             |
  |                            |                             |
  |                            |  {url}?code={code}          |
  |                            |---------------------------->|
  |                            |                             |
  |                            |  user completes action      |
  |                            |<----------------------------|
  |                            |                             |
  |  GET /pending/...                                        |
  |--------------------------------------------------------->|
  |                            |                             |
  |  200 OK                                                  |
  |<---------------------------------------------------------|

13.4.4. Approval Pending

When a server is obtaining approval from another party without requiring the agent to direct a user — for example, via push notification, email, or administrator review:¶

HTTP/1.1 202 Accepted
AAuth-Requirement: requirement=approval
Location: /pending/f7a3b9c
Retry-After: 30

The response MUST include Location and Retry-After. The agent polls the Location URL with GET requests until a terminal response is received. No user action is required at the agent side. The same terminal response codes apply as for interaction.¶

Use cases: Administrator approval, resource owner consent, compliance review, direct user authorization via established communication channel.¶

13.5.1. Initial Request

The agent makes a request and signals its willingness to wait using the Prefer header ([RFC7240]):¶

POST /token HTTP/1.1
Host: auth.example
Content-Type: application/json
Prefer: wait=45
Signature-Input: sig=("@method" "@authority"
    "@path" "signature-key");created=1730217600
Signature: sig=:...signature bytes...:
Signature-Key: sig=jwt;jwt="eyJhbGc..."

{
  "resource_token": "eyJhbGc..."
}

13.5.2. Pending Response

When the server cannot resolve the request within the wait period:¶

HTTP/1.1 202 Accepted
Location: /pending/f7a3b9c
Retry-After: 0
Cache-Control: no-store
Content-Type: application/json

{
  "status": "pending"
}

Headers:¶

• Location (REQUIRED): The pending URL. The Location URL MUST be on the same origin as the responding server.¶
• Retry-After (REQUIRED): Seconds the agent SHOULD wait before polling. 0 means retry immediately.¶
• Cache-Control: no-store (REQUIRED): Prevents caching of pending responses.¶
• AAuth-Requirement (OPTIONAL): Present when user interaction or approval is required. The url and code parameters are defined in Section 13.4.¶

Body fields:¶

• status (REQUIRED): "pending" while the request is waiting. "interacting" when the user has arrived at the interaction endpoint. Agents MUST treat unrecognized status values as "pending" and continue polling.¶

Additional body fields may be present depending on the AAuth-Requirement value — for example, clarification and timeout with requirement=clarification, or required_claims with requirement=claims. See the specific requirement definitions for details.¶

13.5.3. Polling with GET

After receiving a 202, the agent switches to GET for all subsequent requests to the Location URL. The agent does NOT resend the original request body. Exception: During clarification chat, the agent uses POST to deliver a clarification response.¶

The agent MUST respect Retry-After values. If a Retry-After header is not present, the default polling interval is 5 seconds. If the server responds with 429 Too Many Requests, the agent MUST increase its polling interval by 5 seconds (linear backoff, following the pattern in [RFC8628], Section 3.5). The Prefer: wait=N header ([RFC7240]) MAY be included on polling requests to signal the agent's willingness to wait for a long-poll response.¶

13.5.4. Deferred Response State Machine

The following state machine applies to any AAuth endpoint that returns a 202 Accepted response — including PS token endpoints, AS token endpoints, and resource endpoints during call chaining. A non-202 response terminates polling.¶

Initial request (with Prefer: wait=N)
    |
    +-- 200 --> done — process response body
    +-- 202 --> note Location URL, check requirement/code
    +-- 400 --> invalid request — check error field, fix and retry
    +-- 401 --> invalid signature — check credentials;
    |           obtain auth token if resource challenge
    +-- 402 --> payment required (settle payment, poll Location)
    +-- 500 --> server error — start over
    +-- 503 --> back off per Retry-After, retry
               |
               GET Location (with Prefer: wait=N)
               |
               +-- 200 --> done — process response body
               +-- 202 --> continue polling (check status/clarification)
               |           status=interacting → stop prompting user
               +-- 403 --> denied or abandoned — surface to user
               +-- 408 --> expired — MAY initiate a fresh request
               +-- 410 --> gone — MUST NOT retry
               +-- 429 --> slow down — increase interval by 5s
               +-- 500 --> server error — start over
               +-- 503 --> temporarily unavailable
                           back off per Retry-After

13.6.1. Authentication Errors

A 401 response from any AAuth endpoint uses the Signature-Error header as defined in ([I-D.hardt-httpbis-signature-key]). The header, not the response body, is the machine-readable carrier; agents MUST NOT depend on the body for signature error handling.¶

A server returning unsupported_scheme SHOULD include Accept-Signature-Scheme, and one returning unsupported_algorithm SHOULD include Accept-Signature-Alg Section 13.8.4. The error names what went wrong; the header names what would succeed. Because AAuth fixes the scheme Section 13.8.2 and requires Ed25519 support of every agent and resource Section 13.8.1, a conformant agent does not reach either error — the headers exist so that an agent preferring another algorithm, or a client arriving from outside AAuth, can recover in one round trip rather than by trial.¶

13.6.2. Error Response Format

Error response bodies use the HTTP problem details format ([RFC9457]) with Content-Type: application/problem+json. The body is a JSON object with the following members:¶

• error (REQUIRED): String. A single error code, as defined by the endpoint returning the error. This is an RFC 9457 extension member; receivers MUST determine how to proceed from this member.¶
• detail (OPTIONAL): String. A human-readable explanation specific to this occurrence of the error.¶

Other RFC 9457 members (type, title, status, instance) MAY be present with their RFC 9457 semantics. AAuth does not define problem type URIs; receivers MUST NOT rely on type to identify AAuth errors.¶

13.6.3. Token Endpoint Error Codes

Example — the resource token presented to the token endpoint has expired:¶

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{
  "error": "expired_resource_token",
  "detail": "The resource token expired; obtain a new
    resource token from the resource and retry."
}

13.6.4. Polling Error Codes

Example — the user denied the pending request:¶

HTTP/1.1 403 Forbidden
Content-Type: application/problem+json

{
  "error": "denied",
  "detail": "The user declined the request."
}

13.8.1. Signature Algorithms

Agents and resources MUST support Ed25519 ([RFC8032]). Agents and resources SHOULD support ES256. Algorithm identifiers are values from the IANA "JSON Web Signature and Encryption Algorithms" registry [IANA.JOSE.Algorithms], and the alg member of the JWK ([RFC7517]) carries the identifier.¶

Every key AAuth conveys or references is subject to the Algorithm Determination rules of the HTTP Signature Keys specification ([I-D.hardt-httpbis-signature-key]). In particular:¶

• The alg member MUST be present and MUST be a fully-specified identifier — one that determines the signature operation completely, including curve and hash where applicable. A verifier MUST reject a key whose alg is absent.¶
• The polymorphic EdDSA identifier MUST NOT be used. Use Ed25519 (or Ed448), which [RFC9864] registered as its fully-specified replacements when it deprecated EdDSA.¶
• none, any algorithm whose JOSE Implementation Requirement is Prohibited, and symmetric algorithms (the oct key type and the HS256, HS384, and HS512 identifiers) MUST NOT be used.¶
• A verifier MUST reject a key whose kty or, where present, crv disagrees with its alg.¶

Naming Ed25519 rather than EdDSA with the curve pinned separately in prose is what makes the requirement testable: a verifier reading only the alg value cannot distinguish Ed25519 from Ed448, and [RFC9864] deprecates exactly that pattern. ES256 is likewise already fully specified, and its use is RECOMMENDED where a platform's keys are ECDSA on P-256 — notably hardware-backed keys on devices whose secure enclave does not offer Ed25519.¶

Post-quantum algorithms need no special treatment here: the ML-DSA identifiers registered by [RFC9964] are fully specified and are used directly as the alg value.¶

13.8.2. Keying Material

The signing key is conveyed in the Signature-Key header ([I-D.hardt-httpbis-signature-key]). Because every AAuth agent holds an agent token Section 5.2, AAuth uses the identity scheme=jwt: the agent presents a token carrying its public key in a cnf claim, and the key is taken from there. Agents MUST use scheme=jwt; agents MUST NOT use scheme=jwks_uri or scheme=hwk for AAuth resource, PS, or AS requests.¶

Which token the agent presents depends on what the recipient needs to know. All three carry the same key in cnf, so signature verification is identical in each case.¶

The Signature-Key specification also defines pseudonym schemes (scheme=hwk for a bare inline public key, scheme=jkt-jwt for hardware-key delegation). AAuth does not use bare hwk access — the agent token is the minimum AAuth credential. scheme=jkt-jwt is used only in the agent provider's key-refresh ceremony (see [I-D.hardt-aauth-bootstrap]), not for protocol access to resources, PSes, or ASes.¶

See the Signature-Key specification ([I-D.hardt-httpbis-signature-key]) for scheme definitions, key discovery, and verification procedures.¶

13.8.3. Signing (Agent)

The agent creates an HTTP Message Signature ([RFC9421]) on each request, including the following headers:¶

• Signature-Key: Public key or key reference for signature verification¶
• Signature-Input: Signature metadata including covered components¶
• Signature: The HTTP message signature¶

GET /api/documents HTTP/1.1
Host: resource.example
Authorization: AAuth session-token-placeholder
Signature-Input: sig=("@method" "@authority" "@path"
    "authorization" "signature-key");created=1730217600
Signature: sig=:BASE64URL-SIGNATURE-PLACEHOLDER:
Signature-Key: sig=jwt;jwt="eyJhbGciOiJFZERTQSJ9.PLACEHOLDER.PLACEHOLDER"

13.8.4. Verification (Server)

When a server receives a signed request, it MUST perform the following steps. Any failure MUST result in a 401 response with the appropriate Signature-Error header ([I-D.hardt-httpbis-signature-key]).¶

1. Extract the Signature, Signature-Input, and Signature-Key headers. If any are missing, return invalid_request.¶
2. Verify that the Signature-Input covers the required components defined in Section 13.8.3.1. If the server requires additional components, verify those are covered as well. If not, return invalid_input with required_input.¶
3. Verify the created parameter is present and within the server's signature validity window of the server's current time. The default window is 60 seconds. Servers MAY advertise a different window via their metadata (e.g., signature_window in resource metadata). Reject with invalid_signature if outside this window. Servers and agents SHOULD synchronize their clocks using NTP ([RFC5905]).¶
4. Select the Signature-Key dictionary member for the label being verified and read its scheme. If the scheme is not one the server implements — including any scheme this profile does not use Section 13.8.2 and any unregistered value — return unsupported_scheme with an Accept-Signature-Scheme header naming the schemes the server accepts. A server MUST NOT fail in a scheme-specific or undefined manner on an unrecognized scheme.¶
5. Obtain the public key from the Signature-Key header according to the scheme, as specified in ([I-D.hardt-httpbis-signature-key]). Return invalid_key if the key cannot be parsed, unknown_key if the key is not found at the jwks_uri, invalid_jwt if a JWT scheme fails verification, expired_jwt if the JWT has expired, or issuer_missing / issuer_mismatch if the issuer's metadata document fails the checks in Section 13.11.¶
6. Determine the signature algorithm from the alg member of the obtained key, per Section 13.8.1. Return unsupported_algorithm if alg is absent, is a polymorphic identifier, or names an algorithm or key type the server does not implement, and include an Accept-Signature-Alg header naming the algorithms the server accepts. Return invalid_key if the key's kty or crv disagrees with its alg.¶
7. Verify the HTTP Message Signature ([RFC9421]) using the obtained public key and determined algorithm. Return invalid_signature if verification fails.¶

Steps 5 and 6 are ordered so that the algorithm is read from the key the scheme resolved to. Under scheme=jwt the key is the cnf.jwk of the presented token, which the server does not hold until the assertion has been verified.¶

An Accept-Signature-Alg header names exactly the algorithms the server accepts, neither a subset nor a superset, so an agent that selects an algorithm from that list and presents a key carrying it is assured of clearing step 6. A server MAY omit either Accept-Signature-* header where enumerating what it accepts to an unauthenticated caller is judged a disclosure risk, accepting that agents then have to discover the sets by trial or out of band.¶

This profile pins the response status to 401 for every signature failure, where the HTTP Signature Keys specification uses 400 for most of them and permits 401 for the recoverable ones. AAuth requests are authenticated by their signature, so a signature that does not verify is an authentication failure rather than a malformed request, and a single status keeps agent retry logic uniform.¶

A 403 response denies access after the signature verified — authentication succeeded and authorization did not. Per ([I-D.hardt-httpbis-signature-key]), such a response MUST NOT include a Signature-Error, Accept-Signature-Scheme, or Accept-Signature-Alg header. This applies to the AAuth errors returned with 403 (#token-endpoint-error-codes, #polling-error-codes).¶

HTTP/1.1 401 Unauthorized
Signature-Error: error=unsupported_scheme
Accept-Signature-Scheme: jwt

13.10.1. Server Identifiers

The issuer values in metadata documents that identify agent providers, resources, access servers, and person servers MUST conform to the following:¶

• MUST use the https scheme¶
• MUST contain only scheme and host (no port, path, query, or fragment)¶
• MUST NOT include a trailing slash¶
• MUST be lowercase¶
• Internationalized domain names MUST use the ASCII-Compatible Encoding (ACE) form (A-labels) as defined in [RFC5890]¶

Valid identifiers:¶

• https://agent.example¶
• https://xn--nxasmq6b.example (internationalized domain in ACE form)¶

Invalid identifiers:¶

• http://agent.example (not HTTPS)¶
• https://Agent.Example (not lowercase)¶
• https://agent.example:8443 (contains port)¶
• https://agent.example/v1 (contains path)¶
• https://agent.example/ (trailing slash)¶

Implementations MUST perform exact string comparison on server identifiers.¶

13.10.2. Endpoint URLs

The auth_token_endpoint, person_token_endpoint, authorization_endpoint, mission_endpoint, and callback_endpoint values MUST conform to the following:¶

• MUST use the https scheme¶
• MUST NOT contain a fragment¶
• MUST NOT contain a query string¶

When localhost_callback_allowed is true in the agent's metadata, the agent MAY use a localhost callback URL as the callback parameter to the interaction endpoint.¶

13.10.3. Other URLs

The jwks_uri, tos_uri, policy_uri, logo_uri, and logo_dark_uri values MUST use the https scheme.¶

13.11.1. Agent Provider Metadata

Published at /.well-known/aauth-agent.json:¶

{
  "issuer": "https://agent.example",
  "jwks_uri": "https://agent.example/.well-known/jwks.json",
  "name": "Example AI Assistant",
  "description": "**Example AI Assistant** drafts and sends email on your behalf.",
  "logo_uri": "https://agent.example/logo.png",
  "logo_dark_uri": "https://agent.example/logo-dark.png",
  "documentation_uri": "https://agent.example/docs",
  "callback_endpoint": "https://agent.example/callback",
  "event_endpoint": "https://agent.example/events",
  "localhost_callback_allowed": true,
  "tos_uri": "https://agent.example/tos",
  "policy_uri": "https://agent.example/privacy"
}

Fields:¶

• issuer (REQUIRED): The agent provider's HTTPS URL (the domain in agent identifiers it issues). This is the value placed in the iss claim of agent tokens.¶
• jwks_uri (REQUIRED): URL to the agent provider's JSON Web Key Set¶
• name (OPTIONAL): Human-readable agent name¶
• description (OPTIONAL): A Markdown string describing the agent or its provider, for display to users (for example, at a PS consent screen or connected-agents dashboard). Implementations MUST sanitize the Markdown before rendering to users.¶
• logo_uri (OPTIONAL): URL to agent logo (per [RFC7591])¶
• logo_dark_uri (OPTIONAL): URL to agent logo for dark backgrounds¶
• documentation_uri (OPTIONAL): URL with developer documentation for the agent provider¶
• callback_endpoint (OPTIONAL): The agent's HTTPS callback endpoint URL¶
• event_endpoint (OPTIONAL): HTTPS URL at which the AP receives event tokens from resources. Required if the AP supports AAuth Events ([I-D.hardt-aauth-events]).¶
• login_endpoint (OPTIONAL): URL where third parties can direct users to initiate authentication Section 12¶
• localhost_callback_allowed (OPTIONAL): Boolean. Default: false.¶
• tos_uri (OPTIONAL): URL to terms of service (per [RFC7591])¶
• policy_uri (OPTIONAL): URL to privacy policy (per [RFC7591])¶

13.11.2. Person Server Metadata

Published at /.well-known/aauth-person.json:¶

{
  "issuer": "https://ps.example",
  "name": "Example Person Server",
  "description": "**Example Person Server** — manage which agents act for you and review what they do.",
  "logo_uri": "https://ps.example/logo.png",
  "logo_dark_uri": "https://ps.example/logo-dark.png",
  "documentation_uri": "https://ps.example/docs",
  "tos_uri": "https://ps.example/tos",
  "policy_uri": "https://ps.example/privacy",
  "auth_token_endpoint": "https://ps.example/token",
  "person_token_endpoint": "https://ps.example/person",
  "mission_endpoint": "https://ps.example/mission",
  "permission_endpoint": "https://ps.example/permission",
  "audit_endpoint": "https://ps.example/audit",
  "interaction_endpoint": "https://ps.example/interaction",
  "mission_control_endpoint": "https://ps.example/mission-control",
  "jwks_uri": "https://ps.example/.well-known/jwks.json"
}

Fields:¶

• issuer (REQUIRED): The PS's HTTPS URL. MUST match the URL used to fetch the metadata document. This is the value placed in the iss claim of JWTs issued by the PS.¶
• name (OPTIONAL): Human-readable person server name¶
• description (OPTIONAL): A Markdown string describing the person server, for display to users. Implementations MUST sanitize the Markdown before rendering to users.¶
• logo_uri (OPTIONAL): URL to person server logo¶
• logo_dark_uri (OPTIONAL): URL to person server logo for dark backgrounds¶
• documentation_uri (OPTIONAL): URL with developer documentation for the person server¶
• tos_uri (OPTIONAL): URL to terms of service¶
• policy_uri (OPTIONAL): URL to privacy policy¶
• auth_token_endpoint (REQUIRED): URL where agents send token requests¶
• person_token_endpoint (REQUIRED): URL where agents request a person token for a resource Section 6.1¶
• mission_endpoint (OPTIONAL): URL where an agent proposes, updates, and completes the missions it owns Section 9. Present when the PS supports missions. A mission's own URL is {mission_endpoint}/{mission_s256}.¶
• permission_endpoint (OPTIONAL): URL where agents request permission for actions not governed by a remote resource Section 8.4¶
• audit_endpoint (OPTIONAL): URL where agents log actions performed Section 8.5¶
• interaction_endpoint (OPTIONAL): URL where agents relay interactions to the user through the PS Section 8.6¶
• mission_control_endpoint (OPTIONAL): URL of the PS's mission control plane — where parties other than the owning agent read and manage missions: the person, an organization's administrator, or a management service. mission_endpoint is the agent's surface and authenticates callers by agent token; this endpoint serves principals AAuth does not define, so its authentication model, operations, and responses are left to a companion specification Section 9.6. A PS MAY also use it for a deployment's human-facing administrative interface.¶
• revocation_endpoint (OPTIONAL): URL where authorized parties can revoke tokens Section 13.7. This is also where an agent provider revokes an agent token it issued, so that the PS denies the agent token and revokes what it issued for that agent.¶
• jwks_uri (REQUIRED): URL to the PS's JSON Web Key Set¶
• scopes_supported (RECOMMENDED): Array of scope values the PS supports, including identity scopes (e.g., openid, profile, email) and enterprise scopes (e.g., tenant, groups, roles)¶
• claims_supported (RECOMMENDED): Array of identity claim names the PS can provide (e.g., sub, email, name, tenant)¶

13.11.3. Access Server Metadata

Published at /.well-known/aauth-access.json:¶

{
  "issuer": "https://as.resource.example",
  "name": "Example Access Server",
  "description": "**Example Access Server** — issues access for the Example resource.",
  "logo_uri": "https://as.resource.example/logo.png",
  "logo_dark_uri": "https://as.resource.example/logo-dark.png",
  "documentation_uri": "https://as.resource.example/docs",
  "tos_uri": "https://as.resource.example/tos",
  "policy_uri": "https://as.resource.example/privacy",
  "auth_token_endpoint": "https://as.resource.example/token",
  "jwks_uri": "https://as.resource.example/.well-known/jwks.json"
}

Fields:¶

• issuer (REQUIRED): The AS's HTTPS URL. MUST match the URL used to fetch the metadata document. This is the value placed in the iss claim of auth tokens.¶
• name (OPTIONAL): Human-readable access server name¶
• description (OPTIONAL): A Markdown string describing the access server, for display to users. Implementations MUST sanitize the Markdown before rendering to users.¶
• logo_uri (OPTIONAL): URL to access server logo¶
• logo_dark_uri (OPTIONAL): URL to access server logo for dark backgrounds¶
• documentation_uri (OPTIONAL): URL with developer documentation for the access server¶
• tos_uri (OPTIONAL): URL to terms of service¶
• policy_uri (OPTIONAL): URL to privacy policy¶
• auth_token_endpoint (REQUIRED): URL where PSes send token requests¶
• revocation_endpoint (OPTIONAL): URL where authorized parties can revoke tokens Section 13.7¶
• jwks_uri (REQUIRED): URL to the AS's JSON Web Key Set¶

13.11.4. Resource Metadata

Published at /.well-known/aauth-resource.json:¶

{
  "issuer": "https://resource.example",
  "jwks_uri": "https://resource.example/.well-known/jwks.json",
  "access_mode": "auth-token",
  "name": "Example Data Service",
  "description": "**Example Data Service** stores and serves your documents.",
  "logo_uri": "https://resource.example/logo.png",
  "logo_dark_uri": "https://resource.example/logo-dark.png",
  "documentation_uri": "https://resource.example/docs",
  "tos_uri": "https://resource.example/tos",
  "policy_uri": "https://resource.example/privacy",
  "authorization_endpoint": "https://resource.example/authorize",
  "scope_descriptions": {
    "data.read": "Read access to your data and documents",
    "data.write": "Create and update your data and documents",
    "data.delete": "Permanently delete your data and documents"
  },
  "additional_signature_components": ["content-type", "content-digest"]
}

Fields:¶

• issuer (REQUIRED): The resource's HTTPS URL. This is the value placed in the iss claim of resource tokens.¶
• jwks_uri (REQUIRED when the resource issues resource tokens or makes signed calls): URL to the resource's JSON Web Key Set. A resource that only verifies agent signatures for identity-based access — issuing no resource tokens and making no signed requests of its own (e.g., as an agent in multi-hop, #multi-hop) — has no keys to publish and MAY omit jwks_uri.¶
• access_mode (OPTIONAL): The credential flow the resource expects, letting an agent plan its first call without a speculative challenge. This document defines agent-token (identity-only — the agent signs with its agent token), person-token (the resource authorizes on the person's identity alone — the agent signs with a person token), session-token (resource-managed — the agent completes the resource's interaction/consent flow and receives a session token via AAuth-Access), and auth-token (the agent obtains an auth token from its PS using a resource token; the initial call MUST present a person token). Extensions MAY define further values, which are recorded in the AAuth Access Mode Value Registry Section 17.10; R3 ([I-D.hardt-aauth-r3]) defines per-call, for a resource that authorizes each invocation individually against that call's parameters. An agent that does not recognize a declared value proceeds as it would with no declaration, calling the resource and reading the AAuth-Requirement it gets back. Default: agent-token. The declaration is advisory: a resource MAY return any AAuth-Requirement at runtime regardless of the declared mode Section 13.4, and MAY apply different modes to different endpoints — a resource advertising an R3 vocabulary states the mode for an individual operation there ([I-D.hardt-aauth-r3]), and otherwise an agent learns of any variation from the runtime requirement. An agent MAY use access_mode to skip resources its setup cannot satisfy — for example, a PS-less agent (no ps claim in its agent token) cannot complete the auth-token flow.¶
• name (OPTIONAL): Human-readable resource name¶
• description (OPTIONAL): A Markdown string describing the resource, for display to users (for example, at a consent screen). Implementations MUST sanitize the Markdown before rendering to users.¶
• logo_uri (OPTIONAL): URL to resource logo¶
• logo_dark_uri (OPTIONAL): URL to resource logo for dark backgrounds¶
• documentation_uri (OPTIONAL): URL with developer documentation for the resource¶
• tos_uri (OPTIONAL): URL to terms of service¶
• policy_uri (OPTIONAL): URL to privacy policy¶
• authorization_endpoint (OPTIONAL): URL where agents request authorization Section 7.1. When absent, the resource issues resource tokens and interaction requirements via 401 responses (#requirement-auth-token, #resource-managed-auth).¶
• login_endpoint (OPTIONAL): URL where third parties can direct users to initiate authentication Section 12¶
• scope_descriptions (OPTIONAL): Object mapping scope values to Markdown strings for consent display. Scope values are resource-specific; resources that already define OAuth scopes SHOULD use the same scope values in AAuth. Identity-related scopes (e.g., openid, profile, email) follow [OpenID.Core].¶
• signature_window (OPTIONAL): Integer. The signature validity window in seconds for the created timestamp. Default: 60. Resources serving agents with poor clock synchronization (mobile, IoT) MAY advertise a larger value. High-security resources MAY advertise a smaller value.¶
• additional_signature_components (OPTIONAL): Array of HTTP message component identifiers ([RFC9421]) that agents MUST include in the Signature-Input covered components when signing requests to this resource, in addition to the base components required by the HTTP Message Signatures profile ([I-D.hardt-httpbis-signature-key])¶
• revocation_endpoint (OPTIONAL): URL where authorized parties can revoke auth tokens for this resource Section 13.7¶

14.1.1. Consuming a Resource End to End

A resource that wants agents to discover and use it with no prior integration publishes two things in its aauth-resource.json Section 13.11.4:¶

• access_mode — the credential flow the agent should expect: agent-token, person-token, session-token, or auth-token.¶
• An R3 vocabulary. Resources SHOULD advertise an R3 vocabulary (r3_vocabularies, [I-D.hardt-aauth-r3]) describing their operations, so that an agent that knows only the resource's hostname can learn the API and begin using it. The R3 document itself is fetched only by the AS and PS, not the agent; the vocabulary (an OpenAPI, MCP, gRPC, or similar API description) is the agent-facing surface.¶

An agent onboards as follows:¶

1. Fetch aauth-resource.json; read access_mode and the advertised vocabulary.¶
2. Fetch the vocabulary to learn the resource's operations, then construct calls.¶
3. If access_mode is auth-token and the agent has no PS, it cannot complete that flow and SHOULD skip the resource.¶

4. Make the call and satisfy whatever the resource requires, bringing the user in only where the mode calls for it:¶

   • agent-token — the agent signs with its agent token and calls. If the resource needs to bind the agent to a user account (the equivalent of associating an API key with an account), it returns a 202 with requirement=interaction Section 13.4 pointing at a login or account-link page; the agent brings the user there, directly or via the PS's interaction endpoint Section 8.6. Once bound, subsequent calls with the same agent token are recognized with no further interaction. No token is issued — the account-bound agent token is the durable credential.¶
   • session-token — the agent's call, or a request to the authorization_endpoint, triggers a 202 with requirement=interaction pointing at the resource's existing consent or login flow. After the user completes it, the resource returns an opaque token via the AAuth-Access header Section 7.5; the agent presents that token in Authorization: AAuth ..., bound to its signature, on subsequent calls.¶
   • auth-token — the resource issues a resource token via the authorization_endpoint or a 401 Section 7.7. The agent sends it to its PS, which runs consent — bringing the user in at the PS, not the resource — and returns an auth token the agent signs with. Whether the PS asserts identity directly (three-party) or federates with the resource's AS (four-party) is invisible to the agent.¶

Throughout, the agent runs a single loop: make the request, read any AAuth-Requirement, satisfy it — bringing in the user where the requirement directs — and retry. The access_mode declaration lets the agent anticipate the flow; the runtime AAuth-Requirement remains authoritative, so a resource can mix modes across endpoints or escalate at any time.¶

17.4.1. application/aa-agent+jwt

• Type name: application¶
• Subtype name: aa-agent+jwt¶
• Required parameters: N/A¶
• Optional parameters: N/A¶
• Encoding considerations: binary; a JWT is a sequence of Base64url-encoded parts separated by period characters¶
• Security considerations: See Section 15¶
• Interoperability considerations: N/A¶
• Published specification: This document, Section 5.2¶
• Applications that use this media type: AAuth agents, PSes, and ASes¶
• Fragment identifier considerations: N/A¶

17.4.2. application/aa-auth+jwt

• Type name: application¶
• Subtype name: aa-auth+jwt¶
• Required parameters: N/A¶
• Optional parameters: N/A¶
• Encoding considerations: binary; a JWT is a sequence of Base64url-encoded parts separated by period characters¶
• Security considerations: See Section 15¶
• Interoperability considerations: N/A¶
• Published specification: This document, Section 10.4¶
• Applications that use this media type: AAuth ASes, agents, and resources¶
• Fragment identifier considerations: N/A¶

17.4.3. application/aa-person+jwt

• Type name: application¶
• Subtype name: aa-person+jwt¶
• Required parameters: N/A¶
• Optional parameters: N/A¶
• Encoding considerations: binary; a JWT is a sequence of Base64url-encoded parts separated by period characters¶
• Security considerations: See Section 15¶
• Interoperability considerations: N/A¶
• Published specification: This document, Section 6¶
• Applications that use this media type: AAuth PSes, agents, and resources¶
• Fragment identifier considerations: N/A¶

17.4.4. application/aa-resource+jwt

• Type name: application¶
• Subtype name: aa-resource+jwt¶
• Required parameters: N/A¶
• Optional parameters: N/A¶
• Encoding considerations: binary; a JWT is a sequence of Base64url-encoded parts separated by period characters¶
• Security considerations: See Section 15¶
• Interoperability considerations: N/A¶
• Published specification: This document, Section 7¶
• Applications that use this media type: AAuth resources and ASes¶
• Fragment identifier considerations: N/A¶

B.1.1. Why HTTPS-Based Agent Identity

HTTPS URLs as agent identifiers enable dynamic ecosystems without pre-registration.¶

B.1.2. Why Per-Instance Agent Identity

OAuth's client_id identifies an application — every instance of the same app shares a single identifier and typically a single set of credentials. AAuth's aauth:local@domain agent identifier identifies a specific instance with its own signing key. This enables per-instance authorization (grant access to this specific agent process, not all instances of the app), per-instance revocation (revoke one compromised instance without affecting others), and per-instance audit (trace every action to the specific instance that performed it). The agent provider controls which instances receive agent tokens, providing centralized governance over a distributed agent fleet.¶

B.1.3. Why Agents Are Under an Agent Provider

Placing agents under an agent provider rather than allowing each agent to self-certify its own identity serves two purposes. First, scale: a single agent provider can issue, rotate, and revoke agent tokens across a fleet of thousands of instances. Resources and PSes verify agent tokens by fetching the AP's JWKS — one trust anchor for all agents from that provider — rather than performing individual key management with each instance. Second, policy enforcement: the AP is a natural PEP for agents. It controls which agent instances receive tokens, what identity claims they carry, and when tokens are denied or revoked. An agent that is also its own AP would bypass this layer entirely, eliminating the governance point without gaining anything: the protocol complexity increases while the security properties weaken. AAuth therefore requires every agent to hold a token issued by a distinct AP, not self-signed.¶

B.1.4. Why Every Agent Has a Person

Every agent acts on behalf of a person — the entity accountable for the agent's actions. AAuth enables a person server to maintain this link, making it visible and enforceable across the protocol. When present, the PS ensures there is always an accountable party for authorization decisions, audit, and liability.¶

B.1.5. Why Person Tokens

An agent identifier embeds its agent provider's domain, so a person moving to another provider necessarily arrives at a resource as someone new, losing whatever state the resource held for them. The person is the party the resource has a relationship with — the account, the history, and any standing limits are theirs — and keying on (iss, sub) makes that relationship survive the change. It also keeps agent providers from becoming gatekeepers: a resource that never learns which agent product is calling cannot condition access on it.¶

Identifying the person at the authorization endpoint rather than after authorization also lets the resource decide before it commits. Account selection Section 13.3, standing policy for that person, and any per-person limit are all evaluable when the request arrives, instead of after a resource token has been issued and taken to a PS.¶

B.1.6. Why a Mission Belongs to an Agent

A person's relationship with a resource survives their changing agents, but a mission does not: it names one agent, and moving to another means proposing a new mission. The two are different things with different lifetimes. sub identifies the person, durably, because the resource's account and history are theirs. A mission is a grant of latitude to one agent to pursue one piece of work, and the person server evaluates every request against the record of what that agent has already done under it. Carrying that record across a change of agent would attribute one agent's history to another.¶

The practical effect is that anything done under a mission identifier was done by the agent the mission names, which is what makes the mission log worth reading.¶

B.1.7. Why No Agent Identifier Reaches a Resource

Naming the agent, or its provider, in a token the resource reads would restore exactly the coupling the person token exists to remove: a resource able to see either can pin policy to it, and the person's relationship stops surviving a change of agent. So neither the person token, the resource token, nor the auth token carries one. agent_jkt and cnf still bind every request to one key.¶

The agent token still reaches the AS, because a resource deploys an AS to have policy evaluated and an agent token MAY carry claims bearing on that — attestation, platform integrity, workload identity. The resource enforces; the AS evaluates; posture goes to the evaluator. The consequence is that agent-provider independence is complete in three-party and partial in four-party, where the resource has explicitly delegated policy to an AS.¶

B.1.8. Why Identity Alone Can Authorize

A person token carries no authorization, yet a resource in person-identity mode Section 4.1.3 serves requests on it. That is not a contradiction: the person server has authorized nothing, and the resource has decided that knowing the person is enough — the same decision it makes after a login it ran itself. Signing in to a site with an identity provider gets whatever that site gives signed-in people, and no one describes the identity assertion as an authorization.¶

What follows is that issuing a person token is consequential even though it grants nothing. The person server is deciding that this agent may act at this resource as this person, bounded by whatever that resource does on identity. That is why the question put to the person at first issuance is about acting, not naming, and why a person server should know what the resource does with identity before it asks.¶

B.1.9. Why the Mission Is Encoded Rather Than Nested

The approval response carries the mission blob base64url-encoded rather than as a JSON object so that s256 has an unambiguous byte sequence to cover. A nested object has no defined serialization once it is inside an envelope — the receiver would have to re-serialize it to hash it, and any difference in key order, whitespace, or escaping produces a different digest. Encoding makes the string itself the bytes, so the agent decodes, hashes, and compares, which is the operation it already performs on a JWT payload.¶

An earlier revision avoided the problem by making the response body the mission and putting s256 in a header, which worked but left no room in the response for anything else. The encoded member restores that room without giving up verifiability.¶

B.1.10. Why the Mission Identifier Is a Hash

An opaque identifier would name the mission but leave the person server free to attach it to different text afterwards. A digest binds every token carrying mission_s256 to one specific mission, so the mission in the log and the mission those tokens authorized are demonstrably the same. Verification is available to the agent at approval and to anyone holding the blob later.¶

B.1.11. Why a Resource Token Names the Person Token

Binding by presented_jti rather than by comparing claims is what makes mission stripping detectable. A resource cannot drop mission_s256 and present the result as an unscoped request, because the person server resolves the person token it actually issued and compares. Comparing claims alone cannot work: an agent running concurrent missions holds several person tokens for the same resource, so "the person token issued for this agent and resource" does not identify one, and a resource that omitted mission_s256 could not be caught. Naming the token resolves it exactly, and the person server compares everything it issued in one lookup.¶

B.1.12. Why Tool Pre-Approval Is Not Enforced

Tool use is local to the agent. No party the protocol can hold to account observes it, so approved_tools is a record of what the person agreed to rather than a control that stops anything. Its value is that a departure from it is visible afterwards, in the mission log and in what the agent reports to the audit endpoint.¶

The enforcement that does exist sits outside the protocol and is worth naming: the runtime that decides whether to call a tool is built by the agent provider, and the agent provider attests the agent. A person's leverage over local actions is therefore their choice of agent provider, not the tool list. The auth token is the only hard control AAuth offers, and it covers remote resources.¶

B.1.13. Why There Is No Delegation Chain Claim

Earlier revisions recorded the upstream chain in an act claim. It served no reader. The immediate caller in a chain signs the request with its own key and presents its own credentials, so a downstream resource already knows who is calling; act named the parties one and two hops further up, which the downstream has no relationship with and cannot evaluate. Those parties are also the person's tooling, disclosed to a resource that did not need them.¶

The chain is held by the person server, which authorizes every hop and holds the mission log. The same reasoning that made the resource stop attributing missions makes it stop recording delegation: the resource enforces, the person server attributes.¶

B.1.14. Why the ps Claim in Agent Tokens

A resource learns the agent's PS from the person token it verifies, but it needs to know the agent has one before that — to decide whether to challenge for a person token at all, and to know that the auth-token flow is available. The ps claim in the agent token provides that, separately from mission governance.¶

B.2.1. Why .json in Well-Known URIs

AAuth well-known metadata URIs use the .json extension (e.g., /.well-known/aauth-agent.json) rather than the extensionless convention used by OAuth and OpenID Connect. The .json extension makes the content type immediately obvious — no content negotiation is needed. More importantly, it enables static file hosting: a .json file served from GitHub Pages, S3, or a CDN works without server-side configuration. This aligns with AAuth's self-hosted agent model (see [I-D.hardt-aauth-bootstrap]), where an agent's metadata can be published as static files with no active server.¶

B.2.2. Why Standard HTTP Async Pattern

AAuth uses standard HTTP async semantics (202 Accepted, Location, Prefer: wait, Retry-After). This applies uniformly to all endpoints, aligns with RFC 7240, replaces OAuth device flow, supports headless agents, and enables clarification chat.¶

B.2.3. Why JSON Instead of Form-Encoded

JSON is the standard format for modern APIs. AAuth uses JSON for both request and response bodies.¶

B.2.4. Why No Authorization Code

AAuth eliminates authorization codes entirely. OAuth authorization codes require PKCE ([RFC7636]) to prevent interception attacks, adding complexity for both clients and servers. AAuth avoids the problem: the user redirect carries only the callback URL, which has no security value to an attacker. The auth token is delivered exclusively via polling, authenticated by the agent's HTTP Message Signature.¶

B.2.5. Why Callback URL Has No Security Role

Tokens never pass through the user's browser. The callback URL is purely a UX optimization.¶

B.2.6. Why No Refresh Token

AAuth has no refresh tokens. When an auth token expires, the agent obtains a fresh resource token and submits it through the standard authorization flow. This gives the resource a voice in every re-authorization — the resource can adjust scope, require step-up authorization, or deny access based on current policy. A separate refresh token would bypass the resource entirely, and is unnecessary given that the standard flow is a single additional request.¶

B.2.7. Why Reuse OpenID Connect Vocabulary

AAuth reuses OpenID Connect scope values, identity claims, and enterprise parameters. This lowers the adoption barrier.¶

B.3.1. Why a Separate Person Server

The PS is distinct from the AS because they serve different parties with different concerns. The PS represents the agent and its user — it handles consent, identity, mission governance, and audit. The AS represents the resource — it evaluates policy and issues tokens. Combining these into a single entity would conflate the interests of the requesting party with the interests of the resource owner, which is the same conflation that makes OAuth insufficient for cross-domain agent ecosystems.¶

B.3.2. Why Five Resource Access Modes

The modes are not levels of protocol adoption but answers to one question: what does the resource need to know before it serves a request? A resource that only verifies agent signatures can start using AAuth today without deploying a PS or AS. One that needs the person can take a person token and decide for itself. One that wants a scope agreed with the person takes an auth token, and one that wants policy evaluated takes it from its own access server. Each mode is self-contained and useful — not a stepping stone to the "real" protocol — and a resource may use different modes on different endpoints, which is the common case: most calls need only identity, and a few sensitive operations warrant an authorization decision.¶

Resource-managed and person-identity access are kept separate because the difference is who established the person's identity, and that determines what the resource can rely on. In resource-managed access the resource ran its own flow, so it knows the person on its own terms and needs nothing from a person server. In person-identity access it accepts an identity a person server asserted, which is federated login — cheaper for the resource, and dependent on trusting that person server.¶

Agent governance (missions plus permission, audit, and interaction relay) works independently of all five.¶

B.3.3. Why Resource Tokens

In GNAP and OAuth, the resource server is a passive consumer of tokens — it verifies them but never produces signed artifacts. AAuth inverts this: the resource cryptographically asserts what is being requested by issuing a resource token that binds the resource's own identity, the agent's key thumbprint, the requested scope, and the mission context into a single signed JWT. This prevents confused deputy attacks — an attacker cannot substitute a different resource in the authorization flow because the resource token is signed by the resource. It also gives the resource a voice in every authorization and re-authorization, and provides a complete audit artifact linking the request to a specific resource, agent, scope, and mission.¶

B.3.4. Why Session Tokens Are Opaque

In two-party mode, the resource returns an opaque wrapped token via the AAuth-Access header rather than a JWT auth token. This allows the resource to wrap its existing authorization infrastructure (OAuth access tokens, session tokens, etc.) without exposing internal structure. The token is bound to the AAuth signature — the agent includes it in the Authorization header as a covered component — so it cannot be stolen and replayed as a standalone bearer token.¶

B.3.5. Why Missions Are Not a Policy Language

Missions are intentionally not a machine-evaluable policy language. AAuth separates two kinds of authorization decisions:¶

• Deterministic policy is handled by scopes, resource tokens, and AS policy evaluation. These are mechanically evaluable — "does this agent have data.read scope for this resource?" A policy engine (Cedar, OPA/Rego, or any other) can answer this question consistently and automatically.¶

• Contextual governance is handled by missions, justifications, and clarification at the PS. These are the contextual decisions that policy engines cannot answer — "is booking a $10,000 flight reasonable for planning a weekend trip?" or "should this agent access the HR database given what it's trying to accomplish?" The mission description, the agent's justification for each resource access, and the clarification dialog between user and agent provide the context for these decisions.¶

Prior attempts to make authorization semantics machine-evaluable across domains have not scaled. OAuth Rich Authorization Requests (RAR) require clients and servers to agree on domain-specific type values and JSON structures — workable within a single API but combinatorially explosive across arbitrary services. UMA attempted cross-domain resource sharing with machine-readable permission tickets, but adoption stalled because resource owners, requesting parties, and authorization servers could not converge on shared semantics for what permissions meant across organizational boundaries. The fundamental problem is that the meaning of "appropriate access" is contextual, evolving, and domain-specific — it cannot be captured in a predefined vocabulary that all parties share.¶

Missions solve this differently. Rather than requiring all parties to agree on machine-evaluable semantics, AAuth concentrates governance evaluation at the PS — the only party with full context. The PS has the mission description, the user's identity and organizational context, the agent's justification for each request, the history of what the agent has done so far, and a channel to the user for clarification. No other party in the protocol has this context, and no predefined policy language can substitute for it.¶

This context can be presented to humans or to agents acting as decision-makers. The PS does not need to evaluate missions deterministically — it presents the mission context, the justification, and the resource request to whatever decision-maker is appropriate: a human reviewing a consent screen, an AI agent evaluating policy on behalf of an organization, or an automated system applying heuristics. As AI decision-making matures, governance can shift from human review to agent evaluation — without changing the protocol. AAuth standardizes how context is conveyed to the decision-maker; it does not prescribe how the decision is made.¶

The mission's description is Markdown because it represents human intent, not machine policy. The approved_tools array provides structured machine-evaluable elements where appropriate. Resources and access servers do not need the mission content — they enforce their own deterministic policies independently. The mission is a further restriction applied by the PS, and only the PS has sufficient context to evaluate it. Distributing mission semantics to other parties would be both a privacy leak and a false promise of enforcement, since those parties lack the context to evaluate the mission meaningfully.¶

B.3.6. Why Missions Have Only Two States

Missions are either active or terminated. There is no suspended state. An expires_at in the mission blob does not add a state — it declares in advance when the PS will treat the mission as terminated, which the person can see at approval time. A suspended state would require the agent to learn that the mission has resumed, but AAuth has no push channel from the PS to the agent — the agent can only poll. For short pauses (minutes), the deferred response mechanism already provides natural waiting via 202 polling. For long pauses (hours or more), the agent would need to poll indefinitely with no indication of when to stop, making suspension operationally equivalent to termination. Terminating the mission and creating a new one is cleaner — the PS retains the old mission's log for audit, and the new mission can be scoped appropriately for the changed circumstances that prompted the pause. This keeps mission lifecycle simple: a mission is alive until it is done.¶

B.3.7. Why Downstream Scope Is Not Constrained by Upstream Scope

In multi-hop scenarios, downstream authorization is intentionally not required to be a subset of upstream scopes. A flight booking API that calls a payment processor needs the payment processor to charge a card — an operation orthogonal to the upstream scope. Formal subset rules would prevent legitimate delegation chains. Instead, the PS evaluates each hop against the mission context, providing governance-based constraints that are more flexible than algebraic attenuation rules while maintaining a complete audit trail.¶

B.4.1. Why Not mTLS?

Mutual TLS (mTLS) authenticates the TLS connection, not individual HTTP requests. Different paths on the same resource may have different requirements — some paths may require no signature, others a signed request, others verified identity, and others an auth token. Per-request signatures allow resources to vary requirements by path. Additionally, mTLS requires PKI infrastructure (CA, certificate provisioning, revocation), cannot express progressive requirements, and is stripped by TLS-terminating proxies and CDNs. mTLS remains the right choice for infrastructure-level mutual authentication (e.g., service mesh). AAuth addresses application-level identity where progressive requirements and intermediary compatibility are needed.¶

B.4.2. Why Not DPoP?

DPoP ([RFC9449]) binds an existing OAuth access token to a key, preventing token theft. AAuth differs in that agents can establish identity from zero — no pre-existing token, no pre-registration. The agent signs with its own agent token Section 5.2, which it obtains from its agent provider without any resource-side registration; no resource- or AS-issued token is needed to make the first identified call. DPoP has a single mode (prove you hold the key bound to this token), while AAuth supports progressive requirements from verified agent identity through authorized access with interactive consent. DPoP is the right choice for adding proof-of-possession to existing OAuth deployments.¶

B.4.3. Why Not Extend GNAP

GNAP ([RFC9635]) shares several motivations with AAuth — proof-of-possession by default, client identity without pre-registration, and async authorization. A natural question is whether AAuth's capabilities could be achieved as GNAP extensions rather than a new protocol. There are several reasons they cannot.¶

Resource tokens require an architectural change, not an extension. In GNAP, as in OAuth, the resource server is a passive consumer of tokens — it verifies them but never produces signed artifacts that the access server consumes. AAuth's resource tokens invert this: the resource cryptographically asserts what is being requested, binding its own identity, the agent's key thumbprint, and the requested scope into a signed JWT. Adding this to GNAP would require changing its core architectural assumption about the role of the resource server.¶

Interaction chaining requires a different continuation model. GNAP's continuation mechanism operates between a single client and a single access server. When a resource needs to access a downstream resource that requires user consent, GNAP has no mechanism for that consent requirement to propagate back through the call chain to the original user. Supporting this would require rethinking GNAP's continuation model to support multi-party propagation through intermediaries.¶

The federation model is fundamentally different. In GNAP, the client must discover and interact with each access server directly. AAuth's model — where the agent only ever talks to its PS, and the PS federates with resource ASes — is a different trust topology, not a configuration option. Retrofitting this into GNAP would produce a profile so constrained that it would be a distinct protocol in practice.¶

GNAP's generality is a liability for this use case. GNAP is designed to be maximally flexible — interaction modes, key proofing methods, token formats, and access structures are all pluggable. This means implementers must make dozens of profiling decisions before arriving at an interoperable system. AAuth makes these decisions prescriptively: one token format (JWT), one key proofing method (HTTP Message Signatures), one interaction pattern (interaction codes with polling), and one identity model (local@domain with HTTPS metadata). For the agent-to-resource ecosystem, this prescriptiveness is a feature — it enables interoperability without bilateral agreements.¶

In summary, AAuth's core innovations — resource-signed challenges, interaction chaining through multi-hop calls, PS-to-AS federation, mission-scoped authorization, and clarification chat during consent — are architectural choices that would require changing GNAP's foundations rather than extending them. The result would be a heavily constrained GNAP profile that shares little with other GNAP deployments.¶

B.4.4. Why Not Extend WWW-Authenticate?

WWW-Authenticate ([RFC9110], Section 11.6.1) tells the client which authentication scheme to use. Its challenge model is "present credentials" — it cannot express progressive requirements, authorization, or deferred approval, and it cannot appear in a 202 Accepted response.¶

AAuth-Requirement and Accept-Signature coexist with WWW-Authenticate. A 401 response MAY include multiple headers, and the client uses whichever it understands:¶

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api"
Accept-Signature: sig=("@method" "@authority" "@path");sigkey=uri

A 402 response MAY include WWW-Authenticate for payment (e.g., the Payment scheme defined by the Micropayment Protocol ([I-D.ryan-httpauth-payment])) alongside Accept-Signature for authentication or AAuth-Requirement for authorization:¶

HTTP/1.1 402 Payment Required
WWW-Authenticate: Payment id="x7Tg2pLq", method="example",
    request="eyJhbW91bnQiOiIxMDAw..."
Accept-Signature: sig=("@method" "@authority" "@path");sigkey=jkt

B.4.5. Why Not Extend OAuth?

OAuth 2.0 ([RFC6749]) was designed for delegated access — a user authorizes a pre-registered client to act on their behalf at a specific server. Extending OAuth for agent-to-resource authorization would require changing its foundational assumptions:¶

• Client identity: OAuth clients have no independent identity. A client_id is issued by each authorization server — it is meaningless outside that relationship. AAuth agents have self-sovereign identity (aauth:local@domain) verifiable by any party.¶
• Pre-registration: OAuth requires clients to register with each authorization server before use. AAuth agents call resources they have never contacted before — the first API call is the registration.¶
• Bearer tokens: OAuth access tokens are bearer credentials — anyone who holds the token can use it. AAuth binds every token to a signing key via HTTP Message Signatures — a stolen token is useless without the private key.¶
• No resource identity: OAuth does not cryptographically identify the resource. AAuth resources sign resource tokens, binding their identity to the authorization flow.¶
• No governance layer: OAuth has no concept of missions, permission endpoints, audit logging, or interaction relay. These would need to be built on top as extensions, losing the coherence of a protocol designed around them.¶
• No federation model: OAuth's authorization server is always the resource owner's server. AAuth separates the person server (user's choice) from the access server (resource's choice) and defines how they federate.¶

The Model Context Protocol (MCP) illustrates these limitations. MCP adopted OAuth 2.1 for agent-to-server authorization and immediately needed Dynamic Client Registration ([RFC7591]) because agents cannot pre-register with every server. But Dynamic Client Registration gives the agent a different client_id at each server — the agent still has no portable identity. Tokens are bearer credentials, so a stolen token grants full access. There is no resource identity — the server does not cryptographically prove who it is. There is no governance layer — no missions, no permission management, no audit trail. And the entire authorization model is per-server: each MCP server has its own authorization server, and the agent must discover and register with each one independently. MCP's experience demonstrates that OAuth can be made to work for the first API call, but it cannot provide the identity, governance, and federation that agents need as they operate across trust domains.¶

Rather than layer these changes onto OAuth — which would break backward compatibility and produce something unrecognizable — AAuth is a new protocol designed for the agent model from the ground up. AAuth complements OAuth: resources can wrap existing OAuth infrastructure behind the AAuth-Access token, and PSes can delegate user authentication to OpenID Connect providers.¶