Mission-Bound Authorization for AAuth

Status of This Memo

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

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

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

This Internet-Draft will expire on 8 January 2027.¶

Copyright Notice

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

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

Table of Contents

1. Introduction

The AAuth protocol [I-D.draft-hardt-oauth-aauth-protocol] defines agent-to-resource authorization in which an agent holds its own cryptographic identity and a Person Server (PS) brokers user consent. AAuth includes a native mission concept: the agent proposes a mission at the PS, the PS and user clarify and approve it, and the approved mission is referenced by the pair of the approver URL and s256, the hash of the mission JSON. The reference travels in the AAuth-Mission header, covered by the HTTP Message Signature [RFC9421] on every request, and is echoed in the mission claim of resource and auth tokens. The PS keeps a mission log and evaluates every subsequent request against the mission's intent.¶

AAuth deliberately leaves three things open. The mission JSON's structure beyond four required members is implementation-defined. The mission has exactly two states, active and terminated, with "transitions beyond completion", including revocation, deferred to a companion specification. And how the PS evaluates a request against the mission is unspecified PS policy. This document supplies exactly those pieces from the Mission model of [I-D.draft-mcguinness-oauth-mission] (the "issuance profile"): the mission blob carries the structured Mission record with its integrity anchors, the propose-clarify-approve interaction is profiled as the approval event, the full Mission lifecycle governs with revoked and expired added and the only-active rule gating every PS surface, and the family's governance, enforcement, and evidence profiles compose against the result.¶

The headline property is issuance gating. In AAuth's PS-asserted mode the PS issues the auth token itself; in the federated mode the PS is the mandatory gate through which the resource's Access Server is reached. Either way, no auth token exists under a Mission without passing the PS, so this binding gates credential issuance on Mission state exactly as the issuance profile gates derivation. That is the property the family's standalone OAuth binding, the Mission Authority Server [I-D.draft-mcguinness-mission-authority-server], structurally forgoes.¶

This is the third binding of the Mission model and the first to a non-OAuth substrate: the issuance profile binds the model to the OAuth Authorization Server, the Mission Authority Server binds it to a standalone service beside an unchanged AS, and this document binds it to the AAuth Person Server.¶

2. Mission Roles

The AAuth approver URL is the Mission issuer: AAuth fixes the approver as the PS, so the Mission's issuer is the PS's issuer URL. The Approver is the person the PS represents, or a principal the PS's policy authorizes to approve on that person's behalf. The Agent Provider is out of scope as agent identity is throughout the family: it supplies the acting identity the Mission's client_id records, and this profile adds no requirement to it.¶

3. Mission Record

AAuth's mission blob is the JSON object the PS returns at approval, held only by the agent and the PS, and committed by s256 over its exact bytes ([I-D.draft-hardt-oauth-aauth-protocol]). This binding makes the blob the carrier of the Mission record.¶

A Mission-Bound Person Server MUST create a Mission record, as the issuance profile's Mission Record section defines it, for every mission it approves, with issuer equal to the approver URL. The blob MUST include a mission_record member: a JSON object carrying every immutable member of the Mission record, each as the issuance profile's Mission Record section defines it; that section's member list is authoritative and is not restated here. The record's state MUST NOT appear in the blob: the blob is immutable under s256, and state is served by the lifecycle surfaces (Section 6).¶

The mapping into AAuth's vocabulary is fixed as follows:¶

• client_id is the AAuth agent identifier and MUST equal the blob's agent member.¶

• mission_record.issuer MUST equal the blob's approver member.¶

• subject and approver are {iss, sub} objects whose iss is the PS's issuer URL: in AAuth the PS is the party that asserts user identity.¶

• intent.goal MUST equal the blob's description: the approved Markdown description is the recorded goal.¶

• expires_at is REQUIRED (Section 6), in RFC 3339 [RFC3339] date-time form.¶

The AAuth-native blob members (approver, agent, approved_at, description, and the optional approved_tools and capabilities) are unchanged. The blob MAY carry additional session members per AAuth; they are committed by s256 but not by the integrity anchors.¶

{
  "approver": "https://ps.example.com",
  "agent": "aauth:reconciler@agent.example",
  "approved_at": "2026-10-15T14:32:11Z",
  "description":
    "Reconcile Q3 invoices and post adjustments under $500.",
  "approved_tools": [
    { "name": "invoices.read",
      "description": "Read invoices",
      "resource": "https://erp.example.com" },
    { "name": "journal-entries.write",
      "description": "Post journal entries",
      "resource": "https://erp.example.com" }
  ],
  "capabilities": ["interaction"],
  "mission_record": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://ps.example.com",
    "intent": {
      "goal":
        "Reconcile Q3 invoices and post adjustments under $500.",
      "resources": ["https://erp.example.com"],
      "constraints": [
        "Read only invoices issued in 2026-Q3.",
        "Post journal entries under $500."
      ],
      "expires_at": "2026-12-31T23:59:59Z"
    },
    "authority_set": [
      { "type": "mission_resource_access",
        "resource": "https://erp.example.com",
        "actions": ["invoices.read"],
        "constraints": {
          "resource_issued_after": "2026-07-01T00:00:00Z",
          "resource_issued_before": "2026-09-30T23:59:59Z"
        } },
      { "type": "mission_resource_access",
        "resource": "https://erp.example.com",
        "actions": ["journal-entries.write"],
        "constraints": {
          "max_amount": { "amount": "500.00", "currency": "USD" }
        } }
    ],
    "authority_hash":
      "sha-256:mdRUVZfU1BG_Bgla4mrLp6Q9NPVTJ-udnn88F1oXqFc",
    "intent_hash":
      "sha-256:_XJAaRanTKlwadKGYDx60Gk6y6tCSYf04HvQRsHTWio",
    "subject": { "iss": "https://ps.example.com", "sub": "alice" },
    "approver": { "iss": "https://ps.example.com", "sub": "alice" },
    "client_id": "aauth:reconciler@agent.example",
    "policy_version": "ps-policy:v4",
    "approval_event_id": "ape_8K2nP4qV9rL3tY6sB1z",
    "created_at": "2026-10-15T14:32:11Z",
    "expires_at": "2026-12-31T23:59:59Z"
  }
}

AAuth-Mission: approver="https://ps.example.com";
    s256="sN5v0poiLW85zY6tKSlxkR10yPkIr-JUr9ttwhiOc0w"

4. Mission Intent

The agent's proposal to the PS's mission_endpoint is the Mission Intent proposal. AAuth defines the proposal as a JSON object with a Markdown description and an optional tools array ([I-D.draft-hardt-oauth-aauth-protocol]). This binding adds two OPTIONAL proposal members:¶

mission_intent:

A Mission Intent object as the issuance profile defines it. The issuance profile's syntactic rules apply unchanged: the object is closed at the top level, the PS MUST bound its size and array lengths, and it is untrusted client input, never authority.¶

resource (on each tools entry):

An absolute URI naming the tool's provider.¶

A Mission-Bound Agent SHOULD include mission_intent. With a structured Intent the PS derives the Authority Set by narrowing, which the issuance profile makes reproducible and auditable; from description and tools alone the derivation is generative, under that profile's disclosure and recording rules for generative derivation. In either case the PS records the approved Mission Intent, with goal equal to the approved description (Section 3) and resources drawn from the tool providers and policy; when the proposal's Intent carries no expires_at, the PS MUST set one by policy, since the record requires it.¶

Tools map to the Authority Set per the issuance profile's Modeling Tools and Function Calls section: the tool's resource member is the entry's resource, tool names are actions, and argument bounds are constraints. For a tool with no resource (a local tool with no remote provider), the PS MUST set the entry's resource to its own issuer URL: the authority is PS-governed local action, and its point-of-use evaluation belongs to the runtime layer, not to issuance. Every approved_tools name MUST appear as an action of an Authority Set entry whose resource is the tool's provider or the PS's issuer URL, so the AAuth-native tool list and the committed authority cannot diverge.¶

AAuth's permission endpoint remains the per-call path for actions outside the Authority Set: each grant there is an individually approved action recorded in the mission log, and it does not widen the committed set. The proposal is exactly the shaping profile's Mission Intent proposal; a deployment that shapes free-text instructions into structured Intents composes here unchanged ([I-D.draft-mcguinness-mission-shaping]).¶

5. Mission Approval

AAuth's propose, clarify, approve interaction is the approval event. It is natively asynchronous: the PS returns a 202 deferred response while review runs, so no approval blocks a front-channel redirect, exactly as at a Mission Authority Server ([I-D.draft-mcguinness-mission-authority-server]). It executes the issuance profile's approval steps, mapped onto the interaction:¶

1. Authenticate the Approver: the person the PS represents, or a principal the PS's policy authorizes to approve for that person. When a structured Intent carries controls.acr, the authentication MUST be one the deployment's policy maps as satisfying the named class.¶

2. Establish the Subject: the PS MUST itself establish the Subject's (iss, sub), with iss its own issuer URL, and MUST NOT take the Subject from unauthenticated client input.¶

3. Derive the Authority Set from the proposal (Section 4) and render it for consent under the issuance profile's rendering rules. The Markdown description and the agent's clarification messages are attacker-influenceable text: the PS MUST render them inert and sanitized, mitigate direction-override and confusable presentation, and visually distinguish the derived Authority Set from client-supplied text (Section 12.1).¶

4. Compute the integrity anchors with the PS's issuer URL as the envelope iss.¶

5. Create the Mission record in the active state atomically with the approval decision, construct the blob around it, and compute s256 over the response bytes. The PS MUST NOT return the approved (approver, s256) reference before the record is active.¶

Per AAuth, the PS or user MAY refine the description and tools during clarification, and the approved mission MAY differ from the proposal. The recorded Intent and Authority Set are the refined ones; if the derived Authority Set changes between rendering and consent, the PS MUST recompute and re-obtain consent per the issuance profile. Mission Consent Evidence composes unchanged, with the PS as the committing issuer ([I-D.draft-mcguinness-oauth-mission-consent-evidence]); AAuth's clarification chat is the shaping profile's clarification step ([I-D.draft-mcguinness-mission-shaping]).¶

6. Mission Lifecycle

AAuth gives a mission two states, active and terminated, and defers transitions beyond completion to a companion specification. This binding supplies them: the Mission lifecycle is the issuance profile's state space, extended by the status profile where the deployment adopts it ([I-D.draft-mcguinness-oauth-mission-status]), and the only-active rule governs, with unrecognized states fail-safe non-active.¶

AAuth's two states are a projection of this space: only active maps to active, and every terminal state surfaces on AAuth endpoints as the mission_terminated error with mission_status terminated, which already instructs the agent to stop. The family surfaces (Section 6.2) report the distinct state. This binding adds to AAuth's model:¶

• Revocation. The PS MUST provide an authenticated means for the Subject, the Approver, or an administrator to revoke a Mission by mission_id, independent of any token, per the issuance profile. AAuth's revocation scenario in which "the PS revokes a mission" is this transition to revoked; on revocation the PS SHOULD revoke outstanding auth tokens issued under the Mission at the resources' revocation endpoints, as AAuth provides.¶

• Expiry. expires_at is REQUIRED on the record. When it passes, the Mission transitions to expired without a request.¶

• Completion. AAuth's propose-completion interaction is the completion transition: when the user accepts the summary, the PS commits the Mission to completed, with the semantics of the status profile's complete operation. The completion profile's terminal_when constraint composes unchanged ([I-D.draft-mcguinness-oauth-mission-completion]).¶

• Suspension. A PS that adopts the status profile's suspended state MUST NOT report mission_terminated for a suspended Mission, since termination is permanent to the agent; it defers processing instead, using AAuth's 202 deferred mechanism, which AAuth's design rationale names as the waiting path for short pauses. For long pauses the PS SHOULD terminate and let a new proposal re-scope the work, per that rationale.¶

7. Mission-Bound Credential

The AAuth auth token is this binding's Mission-bound credential.¶

{
  "iss": "https://ps.example.com",
  "dwk": "aauth-person.json",
  "aud": "https://erp.example.com",
  "sub": "alice",
  "agent": "aauth:reconciler@agent.example",
  "cnf": { "jwk": { "kty": "OKP", "crv": "Ed25519", "x": "..." } },
  "scope": "invoices.read",
  "jti": "at_9Kp2vN7sR1tY8mZ3qX5b",
  "iat": 1793606400,
  "exp": 1793610000,
  "mission": {
    "approver": "https://ps.example.com",
    "s256": "sN5v0poiLW85zY6tKSlxkR10yPkIr-JUr9ttwhiOc0w",
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://ps.example.com",
    "authority_hash":
      "sha-256:mdRUVZfU1BG_Bgla4mrLp6Q9NPVTJ-udnn88F1oXqFc"
  }
}

8. Mission Substrate

The companion profiles of the Mission suite are defined against the Mission model's substrate primitives rather than against OAuth mechanics. This binding provides all of them, including the Mission-bound credential and issuance gating, the two the standalone binding forgoes. Against the architecture's binding checklist ([I-D.draft-mcguinness-mission-architecture]):¶

1. Identifier and issuer: id on the record, issuer the approver URL; the (approver, s256) pair is the wire-native reference to the same Mission (Section 3.2).¶

2. Lifecycle state space: the issuance profile's states with the only-active rule and fail-safe unrecognized states, extended by the status profile where adopted; freshness through the status operation, signals, and the one-hour auth-token lifetime, with a PS-declared staleness bound (Section 6).¶

3. Authority Set representation: the issuance profile's, with its subset rule and Common Constraints, recorded in the blob (Section 3).¶

4. Integrity anchors: the family envelope and canonicalization, iss the PS's issuer URL, carried inside the s256-committed blob (Section 3.1).¶

5. Mission-bound credential: the auth token with the mission claim and signature-covered reference, issued only while the Mission is active (Section 7, Section 6.1).¶

6. Published key material: the PS's keys, resolvable through AAuth's discovery (Section 6.2).¶

7. Audit horizon: PS-declared; the record and the mission log are retained for it.¶

The composition consequences:¶

• The runtime profile and its AuthZEN binding compose credential-carried (Section 7.4); no join is needed.¶

• Status and signals are PS-served; the PS is the transmitting Mission Issuer (Section 6.2).¶

• Shaping, consent evidence, completion, the Mandate, and audit transparency compose unchanged: the PS is the Mission Issuer those profiles name, the committing issuer for consent evidence, the minter of Mandates, and the producer of audit statements.¶

• Child delegation maps naturally to AAuth's parent_agent sub-agent model: sub-agents are individually identified, authorization is parent-mediated, and the PS is the control point. The family profile's request wire is OAuth-bound ([I-D.draft-mcguinness-oauth-mission-child-delegation]), so AAuth-native Child Mission creation is deferred work; today a sub-agent operates under its parent's Mission per AAuth.¶

• Offline attenuation does not apply: AAuth has no offline-mint substrate; every credential is issuer-minted and proof-of-possession bound ([I-D.draft-mcguinness-oauth-mission-attenuation]).¶

• Cross-domain projection does not apply: AAuth's federated mode is its own cross-party mechanism, federating per request at the PS-AS trust layer rather than projecting a Mission into a foreign issuer ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

9. Limitations

Substrate maturity. AAuth is an individual Internet-Draft, and this binding pins its wire behavior to draft-hardt-oauth-aauth-protocol-08. A change to AAuth's mission surfaces revises this document; a deployment tracks both.¶

Blob visibility. Only the agent and the PS hold the mission blob, and AAuth forbids a Resource or AS to dereference the reference. A Resource therefore verifies from token claims and the signature-covered reference, not by recomputing the anchors: it holds no Authority Set unless a token carries authorization details. A deployment that needs Resource-side authority_hash verification uses a Mission Mandate, minted by the PS as the Mission issuer, carrying the committed facts under the PS's signature ([I-D.draft-mcguinness-mission-mandate]).¶

The PS as trusted component. The PS concentrates approval, issuance, and state in one service, so its compromise is Mission Issuer compromise in the security model's terms: forged approvals, arbitrary minting, and false state ([I-D.draft-mcguinness-mission-security-model]). Consent evidence and audit transparency make forgery detectable after the fact; they do not prevent it (Section 12.3).¶

10. Mission Verification Modes

AAuth's default keeps the mission blob with the agent and the PS, so a Resource verifies from the reference and token claims, not by recomputing the anchors (Section 9). That makes resource-side verifiability an explicit axis this binding must name, one the OAuth binding does not have because its tokens always carry the authority payload. A deployment declares which of three modes it serves; the modes are cumulative in what a Resource or auditor can check without trusting PS-private state.¶

Reference-only (the default):

the credential names the Mission by (approver, s256) and carries the granted scope. The PS gate holds (Section 6.1), but a Resource cannot independently verify the Mission's authority; it trusts the PS's evaluation. Federated mode (Section 7.1) is at most this when the Access Server does not carry the family members.¶

Credential-carried:

the auth token additionally carries the mission claim family members (id, issuer, authority_hash), so a Resource can bind the token to a named Mission and its consent anchor, though it still holds no Authority Set to check a specific action against.¶

Resource-verifiable:

the PS additionally provides either token-carried authorization_details or a signed Mission Mandate ([I-D.draft-mcguinness-mission-mandate]) carrying the committed facts, so a Resource or an auditor can verify that a given token or request is within the approved Mission's authority without trusting opaque PS policy or private blob state. A deployment that needs independent resource-side or third-party authority verification MUST serve this mode.¶

These modes are the AAuth-specific verification axis; the family's assurance tiers ([I-D.draft-mcguinness-mission-architecture]) layer on top, and a runtime-enforced or agent-compromise-resistant AAuth deployment claims the corresponding tier there rather than a binding-specific name. Full-provision Mission governance, which the PS gate already provides (Section 6.1), reaches the Runtime-Enforced tier only in the Resource-verifiable mode with the runtime decision contract in force (Section 7.4).¶

11. Conformance

An implementation conforms in one of two roles.¶

A Mission-Bound Person Server:¶

• creates a Mission record for every approved mission and embeds it in the blob as mission_record, computing the integrity anchors with its issuer URL (Section 3);¶

• resolves the (approver, s256) reference to the record at every PS endpoint that takes one (Section 3.2);¶

• executes the approval event of Section 5, creating the record active atomically with the approval decision;¶

• operates the lifecycle of Section 6: authenticated revocation, expires_at enforcement, completion, and the only-active gate at every PS surface, atomic with issuance (Section 6.1);¶

• issues auth tokens as Mission-bound credentials (Section 7.1, Section 7.2), with exp bounded by the Mission's expires_at; and¶

• serves Mission state per Section 6.2 and retains the record and mission log for the audit horizon.¶

A Mission-Bound Agent:¶

• SHOULD propose a structured Mission Intent (Section 4) and treats every proposal as a proposal, never as authority;¶

• stores the blob bytes exactly as received, carries the Mission reference on resource requests, and covers aauth-mission in its request signatures, per AAuth;¶

• respects the only-active rule: it stops on mission_terminated, treats an unrecognized mission_status as non-active, and proposes completion when the task is done; and¶

• treats mission_id and the Mission reference as references, never as credentials.¶

12. Security Considerations

13. Privacy Considerations

The blob stays with the agent and the PS. Task text, constraints, and the full Authority Set do not travel in credentials unless a deployment opts to carry authorization details; by default a Resource sees only the reference and the granted scope. This is a minimization property the OAuth binding does not have, where the token carries the authority payload; the trade is Resource-side enforcement, which here requires opting into token-carried authority or a Mandate (Section 9).¶

Reference correlation. The (approver, s256) pair rides every mission-context request and token, so Resources observing it can correlate the Mission's activity within and across services, and approver identifies the person's PS. This is the deliberate property of the issuance profile's Mission Identifier correlation, and that profile's guidance applies: the stable anchor is what audit and governance key on, and a deployment SHOULD document the correlation it implies. AAuth's directed sub limits subject correlation; the Mission reference is not directed, because it is the anchor.¶

Directed Mission references, in which the PS presents a distinct per-audience reference that still verifies back to the same Mission through PS-signed evidence, would limit this cross-resource correlation as AAuth's directed sub limits subject correlation. They are future work here, parallel to the audience-pairwise references the issuance profile defers ([I-D.draft-mcguinness-oauth-mission]): both trade the stable audit anchor for unlinkability, and neither is a v1 property.¶

14. IANA Considerations

This document has no IANA actions. The registries AAuth establishes belong to that specification, and this binding defines no new AAuth requirement, capability, or platform values. The members this document adds ride inside structures whose extensibility their defining specifications state: mission_record in the PS-produced blob, and id, issuer, and authority_hash inside the mission claim AAuth registers, whose unrecognized members AAuth consumers ignore. Should AAuth establish registries for those members, the members this document defines would be registered there.¶

15. References

Acknowledgments

This document is part of the Mission-Bound Authorization work. It binds the Mission model to the AAuth protocol's Person Server and native mission concept, and builds on the Mission Status and Lifecycle, Mission-Bound Runtime Enforcement, and Mission Authority Server companions.¶

Author's Address