AAuth Protocol

4.2.1. Agent Identity Access

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

Agent                                        Resource
  |                                             |
  | HTTP Sig w/ agent_token                     |
  |-------------------------------------------->|
  |                                             |
  | 200 OK                                      |
  |<--------------------------------------------|

The agent identifier reaches a resource only in this mode and in resource-managed access. In the other three, no token the resource reads carries one Appendix C.1.6.¶

4.2.2. Resource-Managed Access (Two-Party)

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

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

4.2.3. Person Identity Access

The agent obtains a person token for the resource from its PS Section 7.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 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.¶

Agent                                 Resource       PS
  |                                      |            |
  | HTTP Sig w/ agent_token              |            |
  | POST person_token_endpoint           |            |
  |-------------------------------------------------->|
  |                                      |            |
  | person_token (aud = resource)        |            |
  |<--------------------------------------------------|
  |                                      |            |
  | HTTP Sig w/ person_token             |            |
  |------------------------------------->|            |
  |                                      |            |
  | 200 OK                               |            |
  |<-------------------------------------|            |

This is federated login for agents. A resource that needs more than identity for a particular operation challenges for it there, with requirement=auth-token Section 6.5, while continuing to serve the rest on the person token.¶

4.2.4. PS Authorization Access (Three-Party)

The resource has no access server. It accepts identity and consent asserted by whichever PS issued the person token it verified, and applies its own policy to the claims in the auth token the PS returns Section 13.7. Any PS can assert to any resource without bilateral setup.¶

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

1. Presenting its person token, the agent requests access at the resource's authorization endpoint, or calls the resource and receives a 401 challenge carrying a resource token Section 6.¶
2. The agent sends the resource token to its PS, which returns an auth token Section 7.2.¶
3. The agent presents the auth token to the resource.¶

4.2.5. Federated Authorization Access (Four-Party)

The resource has its own access server. The resource token names the AS as its aud, and the PS federates with the AS to obtain the auth token Section 9.¶

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

1. Presenting its person token, the agent requests access at the resource's authorization endpoint, or calls the resource and receives a 401 challenge carrying a resource token Section 6.¶
2. The agent sends the resource token to its PS. The PS federates with the AS named by the resource token's aud Section 9.3, which returns the auth token to the PS.¶
3. The PS returns the auth token to the agent, which presents it to the resource.¶

4.5.1. Missions

A mission is a Markdown description of what the agent intends to accomplish, proposed by the agent and approved by the person at the PS. It is identified by the s256 hash of the approved mission, accumulates context through the mission log, and ends when the person accepts the agent's completion proposal. Missions are OPTIONAL. Section Section 8 defines them.¶

5.3.1. Agent Token Structure

An agent token is a JWT with typ: aa-agent+jwt. Its header and the claims iss, dwk, jti, iat, exp, and cnf are as defined in Section 11.5.1, with:¶

• iss: Agent provider URL¶
• dwk: aauth-agent.json¶
• cnf: jwk is the agent's public key¶
• exp: Agent tokens SHOULD NOT have a lifetime exceeding 24 hours.¶

Required payload claims specific to agent tokens: - sub: Agent identifier (stable across key rotations)¶

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 7.1.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 10.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 10.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.3.2. Agent Token Usage

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

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

5.3.3. Agent Token Verification

Verify the agent token per Section 11.5.2, with typ aa-agent+jwt and dwk aauth-agent.json, then:¶

1. Verify cnf.jwk matches the key used to sign the HTTP request.¶
2. If ps is present, verify it is a valid HTTPS URL conforming to the Server Identifier requirements.¶
3. 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 10.2; the PS additionally enforces the single-level rule Section 10.2 when such a token signs a request.¶

6.5.1. Deferred Delivery

A resource MAY instead deliver the same requirement as a 202 Accepted deferred response Section 11.8, 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 obtains an auth token exactly as in the 401 case, then polls the pending URL with signed GET requests, 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 tell "not executed" from "executed, response lost". The record is keyed by the auth token's jti. If the resource token expires before the agent obtains an auth token, the resource MAY include a fresh one in the AAuth-Requirement header of a later poll response.¶

Which delivery to use is the resource's choice, per invocation. The 401 needs no state and works on any transport; the 202 suits a resource that can hold the invocation. Agents MUST support both.¶

6.6.1. Response without Resource Token

The resource handles authorization itself. If user interaction is needed, it returns a 202 Accepted deferred response with requirement=interaction, as in Section 6.2. When authorization is complete, or can be granted immediately, it returns 200 OK and MAY include an AAuth-Access header Section 6.3:¶

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

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

6.6.2. Response with Resource Token

The resource returns a resource token Section 6.7.1, with aud set to its AS or to the PS that issued the person token, and mission_s256 copied from the person token when it carried one:¶

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

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

6.6.3. Authorization Endpoint Error Responses

Errors use the error response format Section 11.9.2. A person token that fails verification is answered with 401 and Signature-Error Section 11.3.4, not with a code from this table.¶

6.7.1. Resource Token Structure

A resource token is a JWT with typ: aa-resource+jwt. Its header and the claims iss, dwk, jti, iat, and exp are as defined in Section 11.5.1, with iss the resource URL and dwk aauth-resource.json. A resource token carries no cnf; agent_jkt binds it to the agent's key.¶

Required payload claims specific to resource tokens:¶

• aud: The PS URL or the AS URL, as above.¶
• ps: The person server whose namespace sub belongs to: the iss of the person token the request carried, or the ps of the auth token it carried.¶
• sub: The sub of the token the request carried.¶
• presented_jti: The jti of the token the request carried: the person token on the first challenge of a grant, or the auth token on a step-up or per-call challenge. The agent passes that token to the PS as presented_token Section 7.2. Binding the resource token to one presented token is what makes mission stripping detectable Appendix C.1.9.¶
• agent_jkt: JWK Thumbprint ([RFC7638]) of the agent's current signing key.¶

A resource token carries no agent identifier. The recipient learns the agent's identity from the agent token that signs the token request.¶

Optional payload claims:¶

• scope: Requested scopes, as a space-separated string. Present unless a companion specification defines an authorization claim that replaces it, as R3 does ([I-D.hardt-aauth-r3]).¶
• account: Echoes the account parameter of the request that produced this token Section 11.11.¶
• login_hint: A hint about who the authorization is for, per [OpenID.Core] Section 3.1.2.1, for a resource that knows it. The agent passes the value to its PS as the login_hint parameter of the token request Section 7.2 and MUST NOT alter it. The PS MAY ignore it. A resource MUST check the claims in the auth token it receives against what it asked for rather than assuming the hint was honored.¶
• mission_s256: REQUIRED when the presented token carried one, copied unchanged.¶
• tenant: Copied from the presented token when it carried one.¶
• interaction: Present when the resource requires its own user-facing flow, such as an OAuth authorization at a third-party service, before the PS can issue an auth token Section 7.2.3. Contains url, the HTTPS URL of the resource's interaction endpoint, and code, the interaction code to present there.¶

Resource tokens SHOULD NOT have a lifetime exceeding 5 minutes. A resource token's lifetime is independent of any mission it names: the PS verifies that the mission is active when it acts on the token. If a resource token expires before it is redeemed, the agent MUST obtain a fresh one from the resource and submit a new token request. The PS SHOULD remember prior consent decisions within a mission so the user is not re-prompted for the same resource and scope. ASes are not required to enforce replay detection on resource tokens.¶

6.7.2. Resource Token Verification

Verify the resource token per Section 11.5.2, with typ aa-resource+jwt and dwk aauth-resource.json, then:¶

1. Verify aud matches the recipient's own identifier (the PS in three-party, or the AS in four-party).¶
2. Verify agent_jkt matches the JWK Thumbprint of the key used to sign the HTTP request. For a parent-mediated sub-agent authorization Section 10.2, verify it against the subagent_token's cnf.jwk instead, since the parent signs the request.¶
3. Verify the presented_token from the token request Section 7.2 and Section 9.1.1 by its typ: a person token (aa-person+jwt) per Section 7.1.4 or an auth token (aa-auth+jwt) per Section 9.4.3, with two substitutions: aud MUST equal the resource token's iss rather than the verifier's own identifier, and cnf.jwk MUST match the resource token's agent_jkt rather than the key that signed the request. The resource's record check on sub does not apply. A token that fails is rejected with invalid_presented_token, or expired_presented_token when only exp fails. Then verify that the presented token's jti equals presented_jti, that its iss (person token) or ps (auth token) equals the resource token's ps, and that its sub, mission_s256, and tenant match the resource token's exactly, rejecting the resource token with invalid_resource_token on any mismatch or omission. A mismatch against a token that verifies is evidence of tampering and SHOULD be surfaced to operators. A PS MUST verify that ps names itself; an AS MUST verify that ps names the PS that sent the token request.¶
4. 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.¶

6.7.3. Resource Challenge Verification

When an agent receives 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, sub the value in the token the agent presented, and presented_jti that token's jti.¶
6. Verify exp is in the future.¶
7. Send the resource token, with the token the agent presented as presented_token, to the agent's PS's auth token endpoint.¶

7.1.1. Person Token

A person token is a PS-issued JWT that identifies the person an agent acts for to a single resource. It is not a bearer credential — cnf binds it to the agent's signing key — its aud is one resource, and it lives at most one hour. It carries no authorization from the PS: no scope, no account, no permission. Whether identity alone is sufficient to serve a request is the resource's decision, and a resource that decides it is Section 4.2.3 serves whatever it serves on identity — so holding a person token is, at such a resource, effectively access. What a person token MUST NOT do is stand in for an auth token where one is required Section 13.11.¶

A person token asserts that its issuer recognizes this person and that this agent acts for them. It carries no statement about how the person server established the person's identity, and a resource MUST NOT treat it as evidence of identity proofing, of legal identity, or of any assurance level. What it guarantees is continuity: the same (iss, sub) is the same person at this resource over time Section 13.9.¶

The agent presents it via the Signature-Key header in place of its agent token Section 11.3.2. A resource MUST have verified a person token before it issues a resource token Section 6, so the identity and mission a resource records are PS-asserted rather than agent-asserted.¶

7.1.2. Person Token Structure

A person token is a JWT with typ: aa-person+jwt. Its header and the claims iss, dwk, jti, iat, exp, and cnf are as defined in Section 11.5.1, with:¶

• iss: PS URL¶
• dwk: aauth-person.json¶
• cnf: jwk is the agent's public key¶
• exp: Person tokens MUST NOT have a lifetime exceeding 1 hour, and MUST NOT outlive the agent token presented when the token was requested, the upstream_token when the request carried one Section 10.1.1, or, when mission_s256 is present, the mission's expires_at Section 8.2.¶

Required payload claims specific to person tokens:¶

• aud: The URL of the resource this token identifies the person to¶
• sub: Directed user identifier, with the same value the PS uses in the sub claim of auth tokens it issues for this aud Section 9.4.1¶

Optional payload claims:¶

• mission_s256: The mission the agent is operating under Section 8, when the request named one. The base64url-encoded SHA-256 hash of the approved mission JSON, without padding.¶
• tenant: Tenant identifier per OpenID Connect Enterprise Extensions 1.0 [OpenID.Enterprise], declaring the organization the person belongs to. It lets a resource apply organizational policy before it issues anything Section 13.10. It is not part of the identifier; see Section 14.1.¶

{
  "typ": "aa-person+jwt",
  "alg": "Ed25519",
  "kid": "ps-key-1"
}

{
  "iss": "https://ps.example",
  "dwk": "aauth-person.json",
  "aud": "https://resource.example",
  "sub": "8f14e45fceea167a5a36dedd4bea2543",
  "cnf": { "jwk": { "kty": "OKP", "crv": "Ed25519",
                    "x": "NzbLsXh8uDCcd...", "alg": "Ed25519" } },
  "mission_s256": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk",
  "jti": "pt-3ab910",
  "iat": 1730217600,
  "exp": 1730221200
}

A person token MUST NOT contain scope or account.¶

7.1.3. Person Token Usage

Agents present person tokens via the Signature-Key header ([I-D.hardt-httpbis-signature-key]) under the jwt scheme, in place of the agent token:¶

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

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

An agent refreshes a person token before it expires, within the margin of Section 7.9.1, and re-obtains resource tokens and auth tokens against it, so that no token in the chain lapses mid-task. The refresh runs through the resource's authorization endpoint Section 6.6 presenting the fresh person token, which is also what restores a full-length chain: a resource token issued on a step-up names the auth token the request carried, and the auth token issued against it inherits that token's exp Section 9.4.1. This parallels the agent-token guidance in Section 7.9.¶

7.1.4. Person Token Verification

Verify the person token per Section 11.5.2, with typ aa-person+jwt and dwk aauth-person.json, then:¶

1. Verify aud matches the resource's own identifier.¶
2. cnf.jwk is REQUIRED. Verify it matches the key used to sign the HTTP request, applying the same structural checks as auth token verification Section 9.4.3.2.¶

A recipient MUST reject an aa-person+jwt wherever an auth token is required. Only typ distinguishes the two Section 13.11.¶

sub is unique within the issuer, not globally. A resource MUST treat (iss, sub) as the identifier, MUST treat the value as opaque, and MUST NOT match a sub received from one issuer against a record established under another, however the values compare.¶

7.2.1. Auth Token Request

The agent MUST make a signed POST to the PS's auth_token_endpoint with an HTTP Sig Section 11.3, presenting its agent token via the Signature-Key header under the jwt scheme.¶

Request parameters:¶

• resource_token (REQUIRED): The resource token.¶
• presented_token (REQUIRED): The token the agent presented to the resource that issued resource_token, whose jti the resource token's presented_jti names Section 6.7.1: the person token on the first challenge of a grant, or the auth token on a step-up or per-call challenge. The PS verifies it against the resource token Section 6.7.2 and, in four-party, passes it to the AS Section 9.1.1. Its exp bounds the auth token issued Section 9.4.1.¶
• upstream_token (OPTIONAL): The person token or auth token the calling agent presented to the requester, used in call chaining Section 10.1.1. The PS MUST verify it per Section 9.4.5.¶
• 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 10.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 it to the user during consent, MUST present it as agent-asserted content Section 7.4, and MUST sanitize it before rendering. The PS MAY log it. It is also the text the user's clarification questions are asked about Section 7.5. This document does not yet define a section structure for the value Section 3.¶
• login_hint (OPTIONAL): Hint about who to authorize, per [OpenID.Core] Section 3.1.2.1. When the resource token carries a login_hint Section 6.7.1 the agent sends that value unchanged.¶
• 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 15.10. Describes where the agent runs, not what security measures apply there. For display at the consent screen and the connected-agents dashboard. Agent-attested.¶
• device (OPTIONAL): Short human-readable string identifying the device or browser, for display so users can distinguish entries in their connected-agents dashboard (e.g., Chrome on macOS, Pixel 8 (App)). Opaque to receivers. MUST consist of UTF-8 printable characters only and MUST NOT exceed 64 characters. Agents MUST NOT include personally identifying information beyond what the user has chosen. Agent-attested.¶
• capabilities (OPTIONAL): An array of capability values Section 11.7 the agent can handle for this request, the body equivalent of the AAuth-Capabilities header, which is not used on PS endpoints. Within a mission, if omitted, the PS uses the values captured at approval Section 8.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-Key: sig=jwt;jwt="eyJhbGc..."

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

7.2.2. PS Response

The PS returns one of:¶

Direct grant response (200):¶

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

User interaction required (202): a deferred response with requirement=interaction Section 11.6.3, of the same shape as Section 6.2. In four-party mode the PS may also pass a clarification from the AS through to the agent this way Section 9.1.¶

An agent MAY have several token requests pending at the PS at once, for example when a mission needs several resources. Each has its own pending URL and lifecycle, and the PS MUST handle them independently. How the PS manages concurrent user interactions, by batching consent prompts or serializing them, is its own choice.¶

7.2.3. Resource-Initiated Interaction

When the resource token carries an interaction claim Section 6.7.1, the resource needs its own user-facing flow, typically an OAuth authorization at a third-party service, before the PS can issue an auth token. The PS resolves the resource's interaction before presenting its own consent: if the user declines at the resource, PS consent is moot.¶

1. The PS returns 202 to the agent with its own interaction URL, as for any consent interaction.¶
2. The user arrives at the PS's interaction page. The PS shows an interstitial explaining that the resource requires additional permissions.¶
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 flow. The resource MUST redirect the user to the callback URL when its flow completes, successfully or with an error per Section 7.3.1.¶
5. If the callback carries 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. On user approval, the PS issues the auth token and resolves the agent's pending request.¶

A resource's interaction endpoint MUST support the ?code=...&callback=... pattern whether the redirect comes from an agent or from a PS; it need not distinguish the two. The interaction.url MUST be an HTTPS URL; the PS MUST validate this before redirecting and MUST apply its egress admission policy to it.¶

7.3.1. Interaction Callback Errors

When an interaction cannot be completed, 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 7.2.3, the PS maps the callback error to a polling error Section 11.9.4: access_denied to denied, user_abandoned to abandoned, interaction_expired to expired, and server_error and temporarily_unavailable to server_error.¶

7.5.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 body MUST include a clarification field containing the question and MAY include timeout and options.¶

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 in Section 7.5.2. This requirement is used by PSes (delivering user questions to agents) and by ASes (requesting clarification from PSes).¶

7.5.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.¶
3. Cancel request: DELETE the pending URL.¶

A POST body MUST include an action member. A server MUST reject a POST with a missing or unrecognized action with 400 Bad Request.¶

POST /pending/abc123 HTTP/1.1
Host: ps.example
Content-Type: application/json
Signature-Key: sig=jwt;jwt="eyJhbGc..."

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

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

7.5.3. Clarification Limits

PSes MUST enforce a maximum number of clarification rounds; five is RECOMMENDED. Clarification responses are untrusted input and MUST be sanitized before display Section 13.3.¶

7.6.1. Interaction Request

The agent MUST make a signed POST to the PS's interaction_endpoint with an HTTP Sig Section 11.3, presenting its agent token via the Signature-Key header.¶

Request parameters:¶

• type (REQUIRED): 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 (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 (interaction and payment types). When the interaction URL is resource-hosted, the PS resolves once the user has engaged or this window elapses, whichever comes first Section 7.6.2. Absent max_wait, the PS resolves when the user has engaged or it can make no further progress.¶
• question (OPTIONAL): A Markdown string containing a question for the user (question type).¶
• mission_s256 (OPTIONAL): The mission this request belongs to.¶

POST /interaction HTTP/1.1
Host: ps.example
Content-Type: application/json
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"
}

7.6.2. Interaction Response

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

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

When the interaction URL is hosted by a resource, the user completes the interaction at the resource, and the agent holds two pending URLs: the resource's original Location and the PS's relay Location. The resource's pending URL is authoritative. The PS's relay reports only that the relay reached the user: it returns status: "interacting" once the user has engaged, and a terminal response when the PS has done all it can. 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 this interaction, it returns interaction_unavailable Section 7.6.3, and the agent falls back to directing the user itself Section 11.6.3.2. If the PS cannot reach the user and the agent did not declare the interaction capability, it returns user_unreachable Section 11.9.3, which is terminal.¶

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 mission is no longer active, the PS returns a mission status error Section 8.8. The PS SHOULD record all interaction requests and responses; within a mission it records them in the mission log.¶

7.6.3. Interaction Endpoint Errors

Errors use the error response format Section 11.9.2.¶

7.7.1. Permission Request

The agent MUST make a signed POST to the PS's permission_endpoint with an HTTP Sig Section 11.3, presenting 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 and its log.¶

POST /permission HTTP/1.1
Host: ps.example
Content-Type: application/json
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"
}

7.7.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.¶

If the PS requires user input, it returns a deferred response Section 11.8 and the agent polls until a final response. If the mission is no longer active, the PS returns a mission status error Section 8.8. The PS SHOULD record all permission requests and responses; within a mission it records them in the mission log.¶

7.8.1. Audit Request

The agent MUST make a signed POST to the PS's audit_endpoint with an HTTP Sig Section 11.3, presenting 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
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"
  }
}

7.8.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 entry in the mission log and 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 8.8.¶

7.9.1. Expiry and the Refresh Margin

A token is expired the moment a verifier's clock passes its exp, at every party that verifies it Section 11.5.2. A person token or auth token that a resource names in presented_jti is verified by the resource, then by the PS, and in four-party by the AS, with a possible interaction in between, so a token valid at the resource can be expired by the time the AS sees it. And expiry propagates downward: a person token cannot outlive the agent token presented when it was requested, and an auth token cannot outlive the presented token Section 9.4.1, so a token presented with thirty seconds left buys a thirty-second token.¶

The agent is the party to absorb this: it holds every token in the chain. An agent SHOULD refresh an agent, person, or auth token when fewer than five minutes remain before its exp, and SHOULD NOT present one inside that margin. The margin does not apply to a resource token, whose recommended lifetime is five minutes or less Section 6.7.1 and which the agent redeems at once. Five minutes is RECOMMENDED because it equals the recommended maximum lifetime of a resource token: a presented token with five minutes left is still valid whenever a resource token issued against it is redeemed.¶

Refresh runs from the top of the chain: the agent token first Section 5.3, then the person token Section 7.1, then the resource token and auth token against it. Refreshing in the other order produces a token capped by one about to expire.¶

Refresh is not required when the agent will present the token no further. An agent MAY also renew reactively, presenting an auth token until the resource answers 401 with expired_jwt ([I-D.hardt-httpbis-signature-key]) and then re-authorizing, for a request that is idempotent and can bear the extra round trip. The margin matters most for a token another party will name and pass on: presenting one inside the margin risks expired_presented_token downstream Section 11.9.3 after the resource has already accepted it.¶

8.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. The PS that approved the mission is named beside it: by the iss of a person token, the ps claim of a resource or auth token, and the PS a request is made to. The pair is the mission's identity; the blob carries no approver member, since the approver is always the PS.¶

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. Verification is available to the agent at approval and to anyone holding the blob later.¶

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 7.1.¶

9.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 11.3.¶

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.¶
• presented_token (REQUIRED): The token named by the resource token's presented_jti, passed through from the agent's token request Section 7.2. A person token carries the identity the resource saw — sub, tenant, and mission_s256 when present — under the PS's signature; an auth token carries it under the signature of the server that issued it, which on a step-up in four-party is this AS. Its exp bounds the auth token the AS issues Section 9.4.1. A PS MUST NOT present an expired token; it rejects the agent's token request with expired_presented_token Section 11.9.3, and the agent obtains a fresh person token and a fresh resource token.¶
• subagent_token (OPTIONAL): A sub-agent's agent token, present when the PS federates a parent-mediated sub-agent authorization Section 10.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): The upstream_token of the agent's token request, passed through Section 10.1.1. The AS MUST verify it per Section 9.4.5. agent_token is then the intermediary's agent token.¶

The resource token carries the person's identity as ps and sub Section 6.7.1, and the presented token carries the same identity under its issuer's signature, so the AS needs no separate identity parameter and requirement=claims Section 9.2 is reserved for claims beyond it.¶

The AS MUST verify presented_token against the resource token per step 3 of Section 6.7.2, which is the same check the PS made. A person token's iss and an auth token's ps MUST be the PS that signed this request. The errors are those of that step: invalid_presented_token, expired_presented_token, and invalid_resource_token for a mismatch.¶

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.3.1. 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-Key: sig=jwks_uri;id="https://ps.example";
    dwk="aauth-person.json";kid="key-1"

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

9.1.2. AS Response

The PS calls the AS token endpoint and follows the standard deferred response loop Section 11.8: 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 9.2: The AS needs identity claims. The body includes required_claims. The PS MUST provide the requested claims by POSTing to the Location URL. The AS cannot know what claims it needs until it has processed the resource token.¶
• requirement=clarification Section 7.5.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 11.6: 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 11.6: 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 Payment scheme ([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.¶

9.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 11.4.¶
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.¶
7. Verify exp does not exceed the exp of the presented_token the PS presented Section 9.1.1.¶

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 9.4.2. The resource verifies the auth token against the AS's JWKS Section 9.4.3.¶

When the AS answers with a well-formed terminal error, the PS relays it: the response to the agent carries the AS's error value and status in the PS's own problem+json body Section 11.9.2, so that an AS denial and a federation failure are distinguishable. When the PS cannot obtain a verifiable auth token at all — the AS is unreachable, times out, returns a malformed response, or returns an auth token that fails the verification above — the PS returns as_unreachable Section 11.9.3. Either outcome reaches the agent on its pending request when the token request was deferred.¶

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.¶

9.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,           |                       |
  |  presented_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|                       |
  |  {email, tenant}        |                       |
  |------------------------------------------------>|
  |                         |                       |
  |  200 OK (auth_token)    |                       |
  |<------------------------------------------------|
  |                         |                       |

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

9.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 9.3.3.¶
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.¶

9.3.3. 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.3), 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. This is the common shape for an organization: its agents share one PS and its internal resources one AS, the PS gives centralized audit across every agent and mission, and federation is incurred only at the boundary, when an internal agent reaches an external resource.¶

9.4.1. Auth Token Structure

An auth token is a JWT with typ: aa-auth+jwt. Its header and the claims iss, dwk, jti, iat, exp, and cnf are as defined in Section 11.5.1, with:¶

• iss: The URL of the server that issued the auth token — an AS (four-party) or a PS (three-party)¶
• dwk: aauth-access.json when issued by an AS, aauth-person.json when issued by a PS¶
• cnf: jwk is the agent's public key¶
• exp: Auth tokens MUST NOT have a lifetime exceeding 1 hour, MUST NOT expire later than the agent token used to obtain them Section 7.9, and MUST NOT expire later than the presented_token of the token request Section 7.2 and Section 9.1.1 — a person token, which the PS capped at the mission's expires_at when mission_s256 is present Section 7.1.2, or an auth token bounded the same way in its turn. When the token request carried upstream_token Section 10.1.1, the auth token MUST NOT expire later than that token either. A PS-issued auth token carrying mission_s256 MUST NOT expire later than the mission's expires_at Section 8.2.¶

Required payload claims specific to auth tokens: - aud: The URL of the resource the agent is authorized to access. - 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 10.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 14.1. 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 11.11. - 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.¶

9.4.2. Auth Token Usage

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

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

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.¶

9.4.3. Auth Token Verification

A valid JWT signature alone is not a complete AAuth authorization check — both JWT trust and request-context binding must pass.¶

9.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 token it presented to that resource.¶

9.4.5. Upstream Token Verification

An upstream_token is a person token or an auth token. The recipient reads typ to tell which, and rejects any other typ with invalid_upstream_token. Accepting a person token here does not stand it in for an auth token Section 13.11: the parameter is evidence of who the intermediary is acting for, and grants nothing by itself.¶

The intermediary's agent token is the one that signed the request at the PS, presented in the Signature-Key header, and the agent_token parameter at the AS, where the PS signed the request Section 9.1.1. When the PS or AS receives an upstream_token parameter in a call chaining request:¶

1. Verify the upstream token per Person Token Verification Section 7.1.4 or Auth Token Verification Section 9.4.3, with these substitutions: aud MUST equal the intermediary's identifier rather than the verifier's own; cnf.jwk is the calling agent's key and is not compared with the key that signed this request, which is the intermediary's; and for an auth token the resource's record check on sub does not apply. A token that fails is rejected with invalid_upstream_token, expired_upstream_token when only exp fails, or revoked_upstream_token when the recipient holds a revocation for it Section 11.12.¶
2. Verify the issuer. At the PS: a person token's iss MUST be this PS; an auth token's ps MUST be this PS, and its iss MUST be this PS or an AS this PS presented a person token to for that token's aud and sub Section 9.1.1. At the AS: a person token's iss, or an auth token's ps, MUST be the PS that signed the request. The AS does not check an auth token's iss beyond verifying its signature; the PS has already done so.¶
3. Verify the upstream token's aud equals the iss of the intermediary's agent token. The intermediary is its own agent provider Section 10.1.1.1, so this is the one comparison that ties the token the calling agent presented to the party now making the downstream request. A mismatch is rejected with invalid_upstream_token.¶
4. At the PS, identify the calling agent from its own records: the agent it issued the upstream person token to, or the one it issued the person token to that the upstream auth token was obtained with. If the PS has revoked that agent's agent token or its binding to the person Section 13.14, it MUST reject the request with revoked_upstream_token, whether or not it has revoked the upstream token itself. A PS that cannot identify the calling agent MUST reject the request with invalid_upstream_token.¶
5. The PS evaluates the request against the mission and its supervision policy, based on the upstream token's claims and mission context. The resulting downstream authorization is not required to be a subset of any upstream authorization — see Section 10.1.1.¶

10.1.1. Call Chaining

When a resource needs to access a downstream resource on behalf of the caller, it acts as an agent — the intermediary. The upstream token is a token the calling agent presented in the Signature-Key header of a request the intermediary served: a person token when the intermediary served on the person's identity Section 4.2.3, an auth token when it required authorization. A person token the intermediary answered with a challenge for an auth token is not one: the request it came on was not served Section 13.11.¶

An intermediary MAY present the same upstream token for any number of downstream requests until it expires. Downstream access does not outlive it: a person token issued with upstream_token expires no later than the upstream token Section 7.1.2, and so does an auth token issued on a request carrying one Section 9.4.1. Once the upstream token has expired the intermediary uses a later token from the calling agent, which it receives on the agent's next request. A pending downstream request Section 11.8 whose upstream token expires before it completes ends with expired Section 11.9.4, and the intermediary starts over with a later upstream token.¶

The intermediary routes the downstream token requests to the person server the upstream token names: the iss of a person token, the ps of an auth token. The ps claim in the intermediary's own agent token, if it has one, is NOT used for this routing — it names the intermediary's person server, not the person's.¶

The intermediary first obtains a person token for the downstream resource, presenting the upstream token as upstream_token Section 7.1. It then presents that person token at the downstream resource, receives a resource token, and sends it to the same person server's auth token endpoint, along with the person token as presented_token and the upstream token as upstream_token Section 7.2. 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 11.3. The upstream_token is a body parameter — it is neither presented via Signature-Key nor used as the signing key. Its aud is the intermediary and its cnf is the calling agent's key, not the intermediary's, and it serves only as evidence of who the intermediary is acting for. The signature the recipient verifies is therefore always the intermediary's, over its own key.¶

The recipient evaluates the downstream request per Section 9.4.5.¶

10.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.¶

10.2.1. Sub-Agent Identity

A sub-agent has its own agent identity — its own aauth:local@domain identifier and signing key, issued by its parent's agent provider, exactly like a top-level agent. The iss of a sub-agent's agent token MUST equal the iss of its parent's, and a PS MUST reject a subagent_token whose iss differs from that of the signing agent's token with invalid_subagent_token. 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.2 — 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.¶

10.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 10.1.1: each hop is an independent principal with its own grant, rather than recursive sub-agent spawning.¶

10.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 7.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 6, 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), presented_token (the token the sub-agent presented to the resource: the person token from step 1, or the sub-agent's auth token on a step-up), and subagent_token (the sub-agent's agent token).¶

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

   • It verifies the HTTP Message Signature against the parent's cnf.jwk.¶
   • It verifies the subagent_token Section 5.3.3 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 6.7.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 9.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).¶

11.1.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.¶

11.1.2. Endpoint and Other URLs

The auth_token_endpoint, person_token_endpoint, authorization_endpoint, mission_endpoint, and callback_endpoint values MUST use the https scheme and MUST NOT contain a query string or a fragment. The jwks_uri, tos_uri, policy_uri, logo_uri, and logo_dark_uri values MUST use the https scheme.¶

One exception: when localhost_callback_allowed is true in the agent's metadata, the agent MAY use a loopback callback URL with the http scheme (http://localhost or http://127.0.0.1, any port) as the callback parameter to the interaction endpoint, in place of its callback_endpoint.¶

11.2.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"
}

Role-specific fields:¶

• issuer (REQUIRED): The agent provider's HTTPS URL (the domain in agent identifiers it issues). Placed in the iss claim of agent tokens.¶
• jwks_uri (REQUIRED): URL to the agent provider's JSON Web Key Set.¶
• callback_endpoint (OPTIONAL): The agent's HTTPS callback endpoint URL Section 7.3.¶
• 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]).¶
• localhost_callback_allowed (OPTIONAL): Boolean. Default: false.¶

11.2.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"
}

Role-specific fields:¶

• issuer (REQUIRED): The PS's HTTPS URL. Placed in the iss claim of JWTs issued by the PS.¶
• jwks_uri (REQUIRED): URL to the PS's JSON Web Key Set.¶
• auth_token_endpoint (REQUIRED): URL where agents send token requests Section 7.2.¶
• person_token_endpoint (REQUIRED): URL where agents request a person token for a resource Section 7.1.¶
• mission_endpoint (OPTIONAL): URL where an agent proposes, updates, and completes the missions it owns Section 8. 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 7.7.¶
• audit_endpoint (OPTIONAL): URL where agents log actions performed Section 7.8.¶
• interaction_endpoint (OPTIONAL): URL where agents relay interactions to the user through the PS Section 7.6.¶
• mission_control_endpoint (OPTIONAL): URL of the PS's mission control plane, where parties other than the owning agent read and manage missions Section 8.6. Its authentication model, operations, and responses are out of scope for this document. A PS MAY also use it for a deployment's human-facing administrative interface. Editor's note: a mission control companion specification is TBD.¶
• revocation_endpoint (RECOMMENDED): URL where an agent provider revokes an agent token it issued, and where a resource revokes a resource token this PS holds Section 11.12.¶
• 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).¶

The four REQUIRED fields (issuer, jwks_uri, auth_token_endpoint, person_token_endpoint) are the whole of what a conformant PS publishes. The OPTIONAL endpoints add missions, permission checks, audit, and the relay channel to the person; they do not add conformance.¶

11.2.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"
}

Role-specific fields:¶

• issuer (REQUIRED): The AS's HTTPS URL. Placed in the iss claim of auth tokens.¶
• jwks_uri (REQUIRED): URL to the AS's JSON Web Key Set.¶
• auth_token_endpoint (REQUIRED): URL where PSes send token requests Section 9.1.¶
• revocation_endpoint (RECOMMENDED): URL where a PS revokes a person token it presented to this AS, and where a resource revokes a resource token whose aud is this AS Section 11.12.¶

11.2.4. Resource Metadata

Published at /.well-known/aauth-resource.json. A resource MAY publish this document, and SHOULD point agents at it from pages they reach first Section 11.2.5. A resource that publishes none can still verify identity-based access and issue resource tokens and interaction requirements via 401 responses.¶

{
  "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"]
}

Role-specific fields:¶

• issuer (REQUIRED): The resource's HTTPS URL. 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 has no keys to publish and MAY omit it.¶
• access_mode (OPTIONAL): The credential flow the resource expects, so an agent can plan its first call. Values defined by this document: agent-token (the agent signs with its agent token), person-token (the agent signs with a person token), session-token (the agent completes the resource's interaction 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). Default: agent-token. Extensions MAY define further values, recorded in the AAuth Access Mode Value Registry Section 15.11; R3 ([I-D.hardt-aauth-r3]) defines per-call. An agent that does not recognize a value proceeds as with no declaration. The declaration is advisory: a resource MAY return any AAuth-Requirement at runtime Section 11.6 and MAY apply different modes to different endpoints. An agent MAY use access_mode to skip resources its setup cannot satisfy, for example a PS-less agent and auth-token.¶
• authorization_endpoint (OPTIONAL): URL where agents request authorization Section 6.6. When absent, the resource issues resource tokens and interaction requirements via 401 responses.¶
• scope_descriptions (OPTIONAL): Object mapping scope values to Markdown strings for consent display Section 11.10.¶
• signature_window (OPTIONAL): Integer. The signature validity window in seconds for the created timestamp Section 11.3.4. Default: 60. A resource MAY advertise a larger value for agents with poor clock synchronization, or a smaller one.¶
• 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 Section 11.3.3.1.¶
• revocation_endpoint (RECOMMENDED for a resource that accepts person tokens): URL where the issuer of an auth token or person token for this resource revokes it Section 11.12. A resource that accepts only agent tokens receives no revocations and need not publish one.¶

11.2.5. Resource Metadata Link Relation

The aauth-resource link relation ([RFC8288]) lets any HTTP response, and any HTML page, name the resource metadata document that governs what the response describes. It serves an agent that has reached a developer portal or an API host and does not yet have the resource identifier to append /.well-known/aauth-resource.json to.¶

A server MAY include a Link header field in any response:¶

Link: <https://api.example/.well-known/aauth-resource.json>;
    rel="aauth-resource"

An HTML document MAY carry the same relation as a link element in its head:¶

<link rel="aauth-resource"
      href="https://api.example/.well-known/aauth-resource.json">

The target MUST be a server identifier Section 11.1.1 followed by /.well-known/aauth-resource.json. An agent MUST NOT fetch a target of any other form. Having fetched it, the agent verifies the document as any metadata document Section 11.2: its issuer MUST equal the target minus the well-known suffix.¶

A resource SHOULD include the relation on the page at its documentation_uri. A response MAY carry more than one aauth-resource link when it describes several resources, each a resource identifier of its own. The relation says nothing about the response that carries it: a 401 from a resource endpoint still carries its requirement in AAuth-Requirement, and an agent MUST NOT treat the link as a substitute for it.¶

Verifiers do not use this relation. A party verifying a token or a signature discovers keys from the signer's iss and dwk ([I-D.hardt-httpbis-signature-key]), never from a link in content Section 13.6.¶

11.3.1. Signature Algorithms

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

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. 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.¶
• 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.¶

ES256 is RECOMMENDED where a platform's keys are ECDSA on P-256, such as hardware-backed keys whose secure enclave does not offer Ed25519. The ML-DSA identifiers registered by [RFC9964] are fully specified and are used directly as the alg value.¶

11.3.2. Keying Material

The signing key is conveyed in the Signature-Key header ([I-D.hardt-httpbis-signature-key]). Agents MUST use the jwt scheme, presenting a token that carries their public key in cnf; agents MUST NOT use the jwks_uri or hwk scheme 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.¶

A PS, AS, AP, or resource making a signed AAuth request in its own right, such as a PS-to-AS token request Section 9.1.1 or a revocation Section 11.12, MUST use the jwks_uri scheme. The id parameter MUST be the server's issuer as published in its metadata Section 11.2, and dwk MUST be that metadata document's well-known name: aauth-person.json, aauth-access.json, aauth-agent.json, or aauth-resource.json.¶

Signature-Key: sig=jwks_uri;id="https://ps.example";
    dwk="aauth-person.json";kid="key-1"

The recipient resolves id to the caller's identity, which is the iss of every token that server mints. A resource that acts as an agent to reach a downstream resource Section 10.1 signs as an agent: it presents its own agent token under the jwt scheme.¶

AAuth does not use the hwk scheme; the agent token is the minimum AAuth credential. The jkt-jwt scheme is used only in the agent provider's key-refresh ceremony ([I-D.hardt-aauth-bootstrap]).¶

11.3.3. Signing (Agent)

The agent creates an HTTP Message Signature ([RFC9421]) on each request, including the Signature-Key, Signature-Input, and Signature headers.¶

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="eyJhbGciOiJFZDI1NTE5IiwidHlwIjoiYWEtYWdlbnQrand0Iiwia2lkIjoiYXAta2V5LTEifQ.PLACEHOLDER.PLACEHOLDER"

11.3.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_signature.¶
2. Verify that the Signature-Input covers the required components Section 11.3.3.1 and any additional components the server requires. 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 metadata (signature_window in resource metadata). Return invalid_signature if created is older than the window, and clock_skew if it is further ahead of the server's clock than the 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 11.3.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 ([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, clock_skew if the server applies the OPTIONAL bound on iat Section 11.5.2 and the JWT's iat is further ahead of the server's clock than the validity window, revoked_jwt if the JWT verifies and is unexpired but the server holds a revocation for it Section 11.12, or issuer_missing / issuer_mismatch if the issuer's metadata document fails the checks in Section 11.2.¶
6. Determine the signature algorithm from the alg member of the obtained key Section 11.3.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.¶

An Accept-Signature-Alg header names exactly the algorithms the server accepts. A server MAY omit either Accept-Signature-* header where enumerating what it accepts to an unauthenticated caller is judged a disclosure risk.¶

This profile uses 401 for every signature failure, where the HTTP Signature Keys specification uses 400 for most of them Appendix C.2.5. A 403 response denies access after the signature verified. 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 Section 11.9.3 and Section 11.9.4.¶

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

11.5.1. Common JWT Claims

Header:¶

• alg: Signing algorithm, per Section 11.3.1. A fully-specified identifier is REQUIRED; Ed25519 is RECOMMENDED. Implementations MUST NOT accept none, the polymorphic EdDSA identifier, or any symmetric algorithm.¶
• typ: The token type, aa-<type>+jwt. A recipient MUST check typ before acting on any AAuth JWT Section 13.11.¶
• kid: Key identifier of the issuer's signing key in its JWKS.¶

Payload:¶

• iss: The issuer's server identifier Section 11.1.1.¶
• dwk: The issuer's well-known metadata document name, for key discovery ([I-D.hardt-httpbis-signature-key]).¶
• jti: Unique token identifier for replay detection, audit, and revocation Section 11.12.¶
• iat: Issued-at timestamp. REQUIRED. Not a validity check Section 11.5.2.¶
• exp: Expiration timestamp. Lifetime limits are stated per token type.¶
• cnf: Confirmation claim ([RFC7800]) with jwk containing the public key the token is bound to. The JWK MUST carry a fully-specified alg member Section 11.3.1. A resource token carries agent_jkt in place of cnf Section 6.7.1.¶

11.5.2. Common JWT Verification

Verify per [RFC7515] and [RFC7519]:¶

1. Decode the JWT header. Verify typ is the expected type.¶
2. Verify dwk is the expected metadata document name. Discover the issuer's JWKS via {iss}/.well-known/{dwk} per the HTTP Signature Keys specification ([I-D.hardt-httpbis-signature-key]) and Section 11.4. Locate the key matching the JWT header kid and verify the JWT signature.¶
3. Verify exp is in the future, judged by the verifier's own clock. This document defines no tolerance for clock skew on exp.¶
4. Verify iss is a valid server identifier Section 11.1.1.¶

iat is not a validity check. A verifier MAY refuse a token whose iat is ahead of its clock by its own policy; the bound SHOULD be its signature validity window Section 11.3.4, 60 seconds by default. A verifier that refuses answers clock_skew: in the body for a token carried as a request parameter Section 11.9.3, and as Signature-Error: error=clock_skew ([I-D.hardt-httpbis-signature-key]) for the token in the Signature-Key header. A verifier MAY use iat to bound the age of a token by its own policy; this document defines no such bound. exp minus iat MUST NOT exceed the one-hour ceiling of a person token Section 7.1.2 or an auth token Section 9.4.1, and SHOULD NOT exceed the recommended lifetime of an agent token Section 5.3 or a resource token Section 6.7.1.¶

The token's own section adds the checks specific to it. A token presented in the Signature-Key header that fails any of these steps is a signature failure and is answered per Section 11.3.4; a token carried as a request parameter that fails is answered with the parameter's own error code Section 11.9.3.¶

11.6.1. AAuth-Requirement Header Structure

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

• requirement: A Token ([RFC9651], 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.¶

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

11.6.2. Requirement Values

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

An agent that does not recognize the requirement value MUST NOT treat the response as satisfiable, and 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 it does understand.¶

11.6.3. Interaction Required

When a server requires user action, such as authentication, consent, or payment approval, 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 11.6.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                                                  |
  |<---------------------------------------------------------|

11.6.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.¶

11.8.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-Key: sig=jwt;jwt="eyJhbGc..."

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

11.8.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. 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).¶
• AAuth-Requirement (OPTIONAL): Present when user interaction or approval is required Section 11.6.¶

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.¶

11.8.3. Polling with GET

After receiving a 202, the agent switches to GET for all subsequent requests to the Location URL and does not resend the original request body. Exception: during clarification chat, the agent uses POST to deliver a clarification response Section 7.5.2.¶

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 [RFC8628], Section 3.5). The Prefer: wait=N header ([RFC7240]) MAY be included on polling requests.¶

11.8.4. Deferred Response State Machine

The following state machine applies to any AAuth endpoint that returns 202 Accepted. 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
    +-- 502 --> as_unreachable — fresh resource token, retry after backoff
    +-- 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
               +-- 502 --> as_unreachable — fresh resource token, retry after backoff
               +-- 503 --> temporarily unavailable
                           back off per Retry-After

11.9.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 11.3.4.¶

11.9.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.¶

11.9.3. Token Endpoint Error Codes

Token-specific codes exist only for tokens carried as request parameters, and follow the pattern <invalid|expired|revoked>_<parameter>_token. The token in the Signature-Key header has no codes in this table: when it fails, the response is 401 with Signature-Error Section 11.3.4.¶

Example:¶

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."
}

11.9.4. Polling Error Codes

Example:¶

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

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

11.12.1. Revocation Request

The endpoint accepts a signed POST. The caller signs as a server Section 11.3.2, and recipients MUST verify the caller's identity via HTTP Message Signatures. The signature MUST cover content-digest and content-type along with the base components Section 11.3.3.1, at a resource's revocation endpoint as much as a PS's or an AS's.¶

POST /revoke HTTP/1.1
Host: resource.example
Content-Type: application/json
Signature-Key: sig=jwks_uri;id="https://ps.example";
    dwk="aauth-person.json";kid="key-1"

{
  "jti": "unique-token-identifier",
  "exp": 1788727813
}

• jti (REQUIRED): The token to revoke, within the caller's namespace.¶
• exp (REQUIRED): The revoked token's own expiration, which bounds how long the recipient has to remember the revocation.¶

The issuer is not a request parameter. The recipient takes it from the identity it verified on the signature: a caller revokes only its own tokens. Recipients maintaining revocation state MUST key it by (iss, jti), where iss is the verified identity of the caller. A recipient MAY discard an entry once the current time is past exp plus its clock skew tolerance, and MAY reject a revocation whose exp is further in the future than the longest lifetime it accepts for any token.¶

11.12.2. Who Revokes What

11.12.3. Revocation Response

The recipient records the revocation before it calls anyone, then makes every downstream revocation it is going to make Section 11.12.4, and answers 200 OK once each has a terminal outcome. A 200 says the cascade is finished, not that it was started. Whether the recipient holds a record of the token does not enter into it: a recipient that verifies tokens statelessly still answers 200 OK, having recorded the pair. There is no "not found" response Appendix C.2.7. A recipient with nothing downstream, such as a resource, or a PS or AS receiving a resource token revocation, answers at once.¶

A downstream revocation is terminal when it was recorded there, or when it ended in one of two ways:¶

• revocation_unsupported: the downstream party publishes no revocation_endpoint, or answered unsupported_iss. That party honors the tokens until their exp.¶
• revocation_unavailable: the downstream party did not respond, timed out, or returned a 5xx or a malformed response. The caller MAY revoke again later.¶

Body. An AS reports to the PS: its 200 carries a downstream array with one entry per resource it revoked at, each with recipient (the resource identifier) and error (one of the two values above when the revocation there did not succeed, absent when it did). A PS does not report to the agent provider: its 200 to an AP carries an empty body Appendix C.2.8. A recipient with nothing downstream answers with an empty body. A PS MAY report the outcome of a revocation the person initiated to that person, per recipient.¶

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

{
  "downstream": [
    {
      "recipient": "https://resource.example",
      "error": "revocation_unavailable"
    }
  ]
}

A 200 MAY carry no body, and then carries no Content-Type. A non-empty body MUST be application/json and MUST be a JSON object, whose downstream member is OPTIONAL. A caller reads an absent body as the revocation recorded with nothing reported, and a non-empty body it cannot parse as revocation_unavailable.¶

Deferred completion. If the cascade takes longer than the recipient will hold the connection, or a downstream recipient itself answered 202, the recipient returns a 202 Accepted deferred response Section 11.8 and the caller polls the pending URL for the terminal response. The caller MAY say how long it will wait with Prefer: wait ([RFC7240]). Absent Prefer: wait, the recipient SHOULD hold at least long enough for one round trip to each downstream party it will call, on the order of 20 seconds for a PS or an AS. A recipient MAY hold for less than the caller asked for and answer 202 at its own cap.¶

The poller is a server: it polls the pending URL with a signed GET, signing under the same identity that made the revocation, and sends no body. The recipient MUST verify that identity and MUST answer 404 to a poll from any other. Retry-After and Prefer: wait apply as on any other pending URL. The terminal response is what the synchronous path would have returned, or an error from the table below. No AAuth-Requirement is used. A recipient with nothing downstream MUST NOT answer 202.¶

Idempotence. A recipient answering a repeated revocation for the same (iss, jti) records nothing new, re-attempts each downstream revocation that did not succeed, and reports the current outcome. A PS that received revocation_unavailable MAY therefore revoke the person token at the AS again later.¶

Errors use the format in Section 11.9.2:¶

A request whose signature does not verify is answered with 401 and the Signature-Error header Section 11.9.¶

What a recipient will accept. A recipient MAY restrict revocations to issuers it holds tokens from, or has a record of exchanging tokens with, and answer unsupported_iss to the rest. A recipient that accepts any verified issuer SHOULD bound what one issuer can hold, in entries and in rate, and answer rate_limited beyond either.¶

11.12.4. Revocation Cascade

• PS revokes an auth token it issued (three-party): The PS calls the resource's revocation endpoint.¶
• AS revokes an auth token it issued: The AS calls the resource's revocation endpoint.¶
• PS terminates access it federated (four-party): The PS revokes the person token it presented with the token request Section 9.1.1, and the AS cascades to the auth tokens it issued against that person token.¶
• PS revokes a person token it issued: The PS calls the revocation endpoint of the resource named in the token's aud, and of every AS it presented that person token to. The resource MUST refuse subsequent requests presenting the person token and MUST NOT issue a resource token naming it. The AS MUST NOT issue further auth tokens against it, and MUST revoke the auth tokens it already issued against it by calling the revocation endpoint of the resource each names in aud. The PS MUST NOT present a revoked person token to an AS, and rejects a token request whose presented_token is one with revoked_presented_token Section 11.9.3. Where the revoked person token, or an auth token issued against it, was later presented as an upstream_token Section 10.1.1, the PS SHOULD revoke the person tokens it issued from it in the same cascade, at their resources and at the ASes it presented them to.¶
• Resource revokes a resource token it issued: The resource calls the revocation endpoint of the party named in the token's aud, and in four-party that of the ps as well. The recipient MUST NOT issue an auth token against that resource token, rejects a token request naming it with revoked_resource_token Section 11.9.3, and SHOULD terminate a pending request it started for it, which the agent reads as revoked Section 11.9.4. The recipient records the (iss, jti) whether or not it has seen the token, and MAY discard the entry once the current time is past the exp the revocation named plus clock skew.¶
• PS revokes a mission: The PS marks the mission as revoked. All subsequent token requests referencing that mission's s256 are denied. The PS SHOULD revoke outstanding auth tokens issued under the mission.¶
• Agent provider revokes an agent token it issued: The agent provider calls the PS's revocation endpoint. The PS MUST deny subsequent requests presenting that agent token, and SHOULD revoke the person tokens and auth tokens it issued for that agent, and terminate what it federated by the four-party path above. The cascade is by agent identity: the PS revokes every person token and auth token it issued to that agent's sub, whichever agent token the agent presented when it asked. The revocation does not alter the agent-person binding Section 13.14. An agent token the same provider issues later is verified on its own terms. The PS answers the agent provider with an empty 200 once its cascade is terminal.¶
• Agent provider stops issuing agent tokens: Existing agent tokens expire naturally.¶

Records. The parties that cascade retain what they issued. A PS records, for each agent token it accepts, that token's (iss, jti) and the sub it carried, until the agent token's exp plus clock skew. A PS records each person token it issues Section 7.1, and for each auth token it issued or federated against that person token, the jti, the resource it was for, and the exp. An AS records the same for each auth token it issues, along with the presented_jti it was issued against. A person token issued with an upstream_token is recorded with the upstream token's (iss, jti), so a revocation of the earlier person token walks the chain from the PS's own records; an AS records nothing of the chain. An entry MAY be discarded once the current time is past the token's exp plus clock skew.¶

11.12.5. Presenting a Revoked Token

A recipient MUST say that a revoked token was revoked, not that it is malformed or expired. Where it says so depends on how the token was carried:¶

• Agent, person, or auth token in the Signature-Key header: 401 with Signature-Error: error=revoked_jwt ([I-D.hardt-httpbis-signature-key]). A resource refusing a revoked auth token SHOULD also include AAuth-Requirement: requirement=person-token Section 6.4. It MUST NOT answer with requirement=auth-token and a resource token, since the PS or AS would reject a resource token naming a revoked token with revoked_presented_token. For a revoked agent token no requirement repairs it; the agent obtains a fresh one from its provider.¶
• A token carried as a request parameter: the signature verified, so this is not a 401. The recipient returns revoked_<parameter>_token in the response body Section 11.9.3. A pending request already started against a withdrawn resource token, or whose upstream token or agent's agent token is revoked while it waits, terminates with revoked Section 11.9.4, with detail saying which.¶

Verifying a token does not ask the issuer about that token, so a resource learns of a revocation only when one reaches its revocation endpoint. A party that no revocation reaches is bounded by token lifetime alone: at most one hour for an auth token or a person token, five minutes for a resource token, and 24 hours for an agent token presented directly to a resource. Deployments requiring immediate termination should issue shorter-lived tokens rather than rely on revocation reaching every holder.¶

12.1.1. Consuming a Resource End to End

A resource that wants agents to discover and use it with no prior integration SHOULD publish two things in its aauth-resource.json Section 11.2.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 — from the resource identifier's well-known URL, or from an aauth-resource link on the page the agent reached first Section 11.2.5; 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 11.6 pointing at a login or account-link page; the agent brings the user there, directly or via the PS's interaction endpoint Section 7.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 6.3; 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 6.5. 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.¶

15.5.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 13¶
• Interoperability considerations: N/A¶
• Published specification: This document, Section 5.3¶
• Applications that use this media type: AAuth agents, PSes, and ASes¶
• Fragment identifier considerations: N/A¶

15.5.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 13¶
• Interoperability considerations: N/A¶
• Published specification: This document, Section 9.4¶
• Applications that use this media type: AAuth ASes, agents, and resources¶
• Fragment identifier considerations: N/A¶

15.5.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 13¶
• Interoperability considerations: N/A¶
• Published specification: This document, Section 7.1.1¶
• Applications that use this media type: AAuth PSes, agents, and resources¶
• Fragment identifier considerations: N/A¶

15.5.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 13¶
• Interoperability considerations: N/A¶
• Published specification: This document, Section 6¶
• Applications that use this media type: AAuth resources and ASes¶
• Fragment identifier considerations: N/A¶

C.1.1. 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 control over a distributed agent fleet.¶

C.1.2. 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 enforcement 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.¶

C.1.3. 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.¶

C.1.4. 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 11.11, 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.¶

C.1.5. 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.¶

C.1.6. 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 consequence for resource policy is stated in Section 4.2: a decision keyed on the agent identifier holds in the two-party modes and nowhere else.¶

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.¶

C.1.7. Why Identity Alone Can Authorize

A person token carries no authorization, yet a resource in person-identity mode Section 4.2.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.¶

C.1.8. 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.¶

C.1.9. 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 agent hands the person server the token the resource verified, under its issuer's signature, and the person server 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 pins which one, and the jti check rejects a substitute.¶

The same reasoning is why the agent carries the token rather than the person server looking it up. The person server issued the person token and could retain it, but on a step-up the resource token names an auth token, which in four-party the access server issued and the person server never held. The resource, for its part, has nothing to look up by: an auth token carries no reference to the person token or the resource token it followed from, and (ps, sub, agent key) is the tuple just shown not to identify one. So the resource names the token it just verified, the agent passes that token along, and the person server and the access server run one verification with no record on the request path.¶

C.1.10. 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.¶

C.1.11. 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.¶

C.1.12. 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 supervision.¶

C.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.¶

C.2.2. 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.¶

C.2.3. Why issuer Rather Than resource in Metadata

AAuth diverges from RFC 9728 on two points. It uses issuer as the primary identifier field in every metadata document so that a generic Signature-Key verifier can extract the signer identity uniformly from any dwk document without knowing which role it represents. And it uses unprefixed field names (name, tos_uri, policy_uri, documentation_uri) rather than the resource_-prefixed forms, for consistency across all four roles.¶

C.2.4. Why These Covered Components

The four mandated components each close a request-substitution attack, and all four are derivable by the agent at signing time on every platform, including browsers. @method prevents a captured signature from being replayed with a different method; @authority prevents cross-host replay; @path binds it to the endpoint; signature-key prevents key substitution.¶

content-digest and content-type are mandated at PS and AS endpoints because their request bodies carry members that decide what is authorized (justification, mission_s256, resource, the mission proposal itself), and every such endpoint takes a JSON body of known shape, so a digest costs the sender nothing. Resources serve arbitrary APIs, including bodyless requests and streamed uploads, so they declare what they need through additional_signature_components instead. A resource's revocation endpoint is the exception because it is defined by this document, not by the resource's API, and its body selects a token and adds to retained state.¶

C.2.5. Why 401 for Every Signature Failure

The HTTP Signature Keys specification uses 400 for most signature failures 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.¶

C.2.6. Why account Is Not login_hint

account selects; it does not hint. login_hint ([OpenID.Core], Section 3.1.2.1) is a hint about who to authenticate at the party receiving it, and is consumed during a login. Nobody is being authenticated by account: the account is already connected at the resource, and the value has to survive into the issued tokens as a claim. Overloading login_hint would also conflate the person logging in at their PS with the account being acted on at the resource, which may belong to different namespaces entirely.¶

C.2.7. Why a Revocation Has No "Not Found"

A recipient cannot distinguish a token it never saw from one it saw and no longer holds, and an answer that varied with what it holds would disclose that. A 200 says the revocation is recorded and the token will be refused; that is true whether or not the recipient ever held it.¶

C.2.8. Why a PS Reports Nothing to the Agent Provider

Any report to the agent provider, even a count of downstream revocations, would tell it which resources the person uses through that agent, which is what the PS exists to keep from it. The AS's report to the PS discloses nothing, since the PS already knows the resource as the person token's aud. The person is the party the rule protects, so a PS MAY report the per-recipient outcome to them.¶

C.2.9. In Brief

• URL-based server identity: HTTPS URLs as server identifiers, and an agent identifier that names its provider's domain, enable dynamic ecosystems without pre-registration.¶
• Standard HTTP async pattern: 202 Accepted, Location, Prefer: wait, and Retry-After apply uniformly to every endpoint, align with RFC 7240, replace the OAuth device flow, support headless agents, and carry clarification chat.¶
• JSON rather than form encoding: JSON is the standard format for modern APIs, for request and response bodies alike.¶
• The callback URL has no security role: tokens never pass through the user's browser; the callback is a UX optimization.¶
• OpenID Connect vocabulary: reusing its scope values, identity claims, and enterprise parameters lowers the adoption barrier.¶

C.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 person — it handles consent, identity, mission supervision, 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.¶

C.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.¶

C.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.¶

C.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.¶

C.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 supervision 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 supervision 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 the Supervisor Section 4.3: the person at a consent screen, or a supervision server deciding on their behalf — an AI agent applying an organization's policy, or an automated system applying heuristics. As AI decision-making matures, supervision 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.¶

C.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.¶

C.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.¶

C.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.3, 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.¶

C.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; a resource that signs what is being requested Appendix C.3.3 changes that core assumption rather than extending it.¶

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.¶

C.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 the Accept-Signature-* headers ([I-D.hardt-httpbis-signature-key]) 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-Scheme: jwt

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

HTTP/1.1 402 Payment Required
WWW-Authenticate: Payment id="x7Tg2pLq", method="example",
    request="eyJhbW91bnQiOiIxMDAw..."
Accept-Signature-Scheme: jwt