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 11 February 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"), and it supplies them natively: AAuth's own blob members carry the Mission record under a fixed equivalence (the description is the goal, the approved_tools are the Authority Set, the agent is the client_id), three flat members complete what the natives cannot carry, the integrity anchors are computed as a deterministic projection of the s256-committed blob rather than embedded beside the members they commit, the propose-clarify-approve interaction is profiled as the approval event, the full Mission lifecycle rides the mission log 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 (Section 7.1). 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 Authorization Server, and this document binds it to the AAuth Person Server.¶

2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

All JSON shown in this document is non-normative and illustrative; the member definitions in the surrounding text are authoritative.¶

This document uses Mission, Mission Intent, Mission Issuer, Authority Set, Approver, Subject, mission_id, the integrity anchors (intent_hash and authority_hash), the subset rule, the only-active rule, and the audit horizon as defined by [I-D.draft-mcguinness-oauth-mission]. It uses Person Server (PS), Agent Provider, Access Server, agent token, resource token, auth token, mission blob, mission log, the AAuth-Mission header, and the resource access modes as defined by [I-D.draft-hardt-oauth-aauth-protocol]. It additionally uses:¶

Mission-Bound Person Server:

A Person Server conforming to this profile: it implements the Mission Issuer role over AAuth's mission surfaces (Section 13).¶

Mission-Bound Agent:

An AAuth agent that proposes structured intent, carries the Mission reference, and respects the Mission lifecycle (Section 13).¶

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

4. 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 wire carrier of the Mission record without restating it: the blob's native members carry the record's facts under a fixed equivalence, and three flat members carry what the natives cannot. No nested record object is embedded, and no fact is spelled twice.¶

A Mission-Bound Person Server MUST maintain 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 record's equivalence with the blob is fixed as follows:¶

• intent.goal is the blob's description; created_at is approved_at; client_id is agent; issuer is approver.¶

• The Authority Set is the approved_tools array under the projection of Section 4.1: each tool entry is one mission_resource_access entry, its resource the entry's resource, its name the entry's single action, its constraints the entry's constraints. A tool with no resource projects to the PS's own issuer URL, PS-governed local action whose point-of-use evaluation belongs to the runtime layer. This equivalence is definitional, so the AAuth-native tool list and the committed authority cannot diverge: they are one structure.¶

• The approved Mission Intent is the canonical projection of Section 4.1 (goal from description, resources from the tool providers in order of first appearance, expires_at); when the approved Intent carries members the projection cannot express (structured controls, proposed_authority context), the blob carries the approved Intent verbatim in a flat mission_intent member, which then supersedes the canonical projection.¶

Three flat members complete the record, in AAuth's own style:¶

mission_id:

REQUIRED. The Mission Identifier (Section 4.2).¶

expires_at:

REQUIRED (Section 7). RFC 3339 [RFC3339] date-time.¶

policy_version:

REQUIRED. The derivation policy correlator, per the issuance profile.¶

What deliberately does not appear in the blob:¶

• the record's state: the blob is immutable under s256, and state is served by the lifecycle surfaces (Section 7);¶

• the integrity anchors: they are computed from the blob (Section 4.1); and¶

• the subject and approver principals with their approval_event_id: the PS establishes the principals at approval as {iss, sub} objects whose iss is its own issuer URL and records them PS-side, where evidence and the status surfaces join them.¶

Keeping the person out of the portable artifact is AAuth's own directed-identity posture, and this binding follows it.¶

The AAuth-native blob members are otherwise unchanged, and the blob MAY carry additional session members per AAuth. Additional members are committed by s256 and, apart from mission_intent, 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",
      "constraints": {
        "resource_issued_after": "2026-07-01T00:00:00Z",
        "resource_issued_before": "2026-09-30T23:59:59Z"
      } },
    { "name": "journal-entries.write",
      "description": "Post journal entries",
      "resource": "https://erp.example.com",
      "constraints": {
        "max_amount": { "amount": "500.00", "currency": "USD" }
      } }
  ],
  "capabilities": ["interaction"],
  "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "expires_at": "2026-12-31T23:59:59Z",
  "policy_version": "ps-policy:v4"
}

intent_hash    = sha-256:kYYJtTdI2RDrObFOdRDGonB7eRmiB65xwxqnw5Nikbk
authority_hash = sha-256:mdRUVZfU1BG_Bgla4mrLp6Q9NPVTJ-udnn88F1oXqFc

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

5. 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, and it is untrusted client input, never authority. The PS MUST bound its size and array lengths.¶

resource (on each tools entry):

An absolute URI naming the tool's provider.¶

constraints (on each tools entry):

An object of machine-actionable bounds on the tool, in the issuance profile's constraints shape: Common Constraint names with their shared semantics, other names deployment-defined.¶

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 approved Intent is carried by the canonical projection where it fits, and verbatim in the blob's mission_intent member where it does not (Section 4). When the proposal's Intent carries no expires_at, the PS MUST set one by policy, since the record requires it.¶

Derivation lands in the approved_tools shape, consistent with the issuance profile's Modeling Tools and Function Calls section: each derived Authority Set entry is one tool entry, its provider the entry's resource, its name the entry's action, its bounds the entry's constraints. The tools are the Authority Set by definition under the projection of Section 4.1, so the AAuth-native tool list and the committed authority cannot diverge: they are one structure. For a tool with no resource (a local tool with no remote provider), the projection sets the entry's resource to the PS's own issuer URL: the authority is PS-governed local action, and its point-of-use evaluation belongs to the runtime layer, not to issuance.¶

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

6. 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. The PS MUST NOT take the Subject from unauthenticated client input.¶

3. Derive the Authority Set from the proposal (Section 5) 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 14.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 from the approved native members and the flat members (Section 4), and compute s256 over the response bytes; the anchors of step 4 are thereafter recomputable from those bytes (Section 4.1). 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]). When the user questions the proposal rather than the task ("why does this need write access to my finance folder?"), the chat is also the consent-evidence profile's Disclosure Interrogation: an answer the PS presents in its own voice is grounded in recorded shaping or provenance material, the agent's chat replies stay attacker-influenceable text under Section 14.1, and the chat the mission log retains (Section 14.4) is the interrogation record.¶

7. 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. Transitions live in AAuth's own idiom: each is a mission-log event, the log is the authoritative transition history, and AAuth's endpoints surface the current state through the existing mission status machinery.¶

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 7.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 status profile's terminal_when completion constraint composes unchanged ([I-D.draft-mcguinness-oauth-mission-status], Completion section).¶

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

8. 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": "w7zuCFWNcWtDb10bawnuQrMcVRGm9B8PKFpJUMoUzbs",
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://ps.example.com",
    "authority_hash":
      "sha-256:mdRUVZfU1BG_Bgla4mrLp6Q9NPVTJ-udnn88F1oXqFc"
  }
}

9. Mission Substrate

The companion profiles of the Mission suite are defined against the Mission model's substrate primitives rather than against OAuth mechanics. In the PS-asserted mode this binding is full provision in the substrate's terms ([I-D.draft-mcguinness-mission-substrate]): it provides every primitive, including the Mission-bound credential and issuance gating, the two the standalone binding forgoes. In the federated mode full provision holds only when the Access Server carries the family mission members (Section 8.1); a federated deployment whose Access Servers do not is Reference-only (Section 11). Against the substrate's requirements:¶

1. Identifier and issuer: mission_id, a flat blob member; issuer the approver URL; the (approver, s256) pair is the wire-native reference to the same Mission (Section 4.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 7).¶

3. Authority Set representation: the issuance profile's, with its subset rule and Common Constraints, carried as the profiled approved_tools, which are the Authority Set by definition under the projection (Section 4, Section 4.1).¶

4. Integrity anchors: the family envelope and canonicalization, iss the PS's issuer URL, computed as a deterministic projection of the s256-committed blob rather than stored (Section 4.1).¶

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

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

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

8. Approval fidelity: the propose, clarify, approve interaction produces the record, the anchors, and the consent disclosure with the required fidelity (Section 6).¶

The composition consequences:¶

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

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

• Shaping, consent evidence, the status profile's completion machinery, 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 trust layer between the PS and the Access Server rather than projecting a Mission into a foreign issuer ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

• Authorization continuity ([I-D.draft-mcguinness-oauth-mission-continuation]) is native for the over-time case and needs no new transport: the (approver, s256) reference is a handle that grants nothing, and the PS's state-gated, one-hour auth-token issuance and federation is the continuation point, with revocation latency bounded by the token lifetime. That profile's cross-workload transports are OAuth-bound (Identity Continuation and async delegation over token exchange), for which AAuth has no substrate, and AAuth declines cross-hop authority carry-forward by design (Section 8.2): a chained hop is a fresh decision at its own decision point. AAuth-native cross-workload continuation is therefore deferred work, alongside Child Mission creation.¶

10. 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. This document stays Standards Track because the Mission-model content it specifies, the equivalence, the projected anchors, and the lifecycle, is complete and stable in its own terms; the tracked risk is AAuth's substrate maturity, not this document's. This is the same disclosure the offline attenuation profile makes for its own substrate ([I-D.draft-mcguinness-oauth-mission-attenuation]), applied here to a Standards Track document rather than an Experimental one, so the maturity signal reads the same way regardless of category. A deployment that needs a binding whose base conformance floor carries no unratified dependency uses the issuance profile or the standalone Mission Authority Server binding, each of which confines its own Internet-Draft references to an optional capability above that floor ([I-D.draft-mcguinness-oauth-mission], [I-D.draft-mcguinness-mission-authority-server]).¶

Blob visibility. Only the agent and the PS hold the mission blob, and AAuth forbids a Resource or Access Server 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 14.3).¶

11. 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 10). 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 7.1), but a Resource cannot independently verify the Mission's authority; it trusts the PS's evaluation. Federated mode (Section 8.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 Mission Assurance Levels ([I-D.draft-mcguinness-mission-architecture]) layer on top, and a runtime-enforced or agent-compromise-resistant AAuth deployment claims the corresponding level there rather than a binding-specific name. Full-provision Mission governance, which the PS gate already provides (Section 7.1), reaches the Runtime-Enforced level only in the Resource-verifiable mode with the runtime decision contract in force (Section 8.4).¶

12. Resource-Declared Semantics

This section is informative. AAuth's exploratory Rich Resource Requests companion ([I-D.draft-hardt-aauth-r3]) inverts the authority ontology this family inherits from OAuth: instead of the client proposing authority, the resource publishes an R3 document declaring its operations, their human meaning, and their consequences, content-addressed by r3_s256, and the agent carries the hash of a declaration it cannot read. That is the descriptive half of open-world discovery, and it composes with this binding's governance half without new mechanism:¶

• Encounter-time adjudication at the gate that already exists. The Person Server issues or gates every auth token (Section 7.1), so the moment an agent requests a token for a newly encountered resource is the adjudication point: the PS evaluates the resource's declared operations against the Mission's Authority Set, or against a pre-consented ceiling where the progressive companion is deployed ([I-D.draft-mcguinness-oauth-mission-progressive]), binding in-envelope encounters by policy and routing everything else to the Approver.¶

• Consent composes the resource's own words. The R3 display section is resource-authored consent material; a PS that renders it into a Mission's approval or expansion disclosure gives the Approver the resource's stated meaning and consequences, and Consent Evidence then commits what was shown ([I-D.draft-mcguinness-oauth-mission-consent-evidence]).¶

• A third commitment. r3_s256 commits what the resource declared, beside intent_hash (what the client asked) and authority_hash (what was consented). Recorded with binding and decision evidence (the progressive companion's resource_declaration_digest carries it), it makes the encounter reproducible in audit: what the resource claimed to be at the moment authority bound to it.¶

R3 is an exploratory draft; this section describes composition, not a normative dependency, and nothing in this binding's conformance requires it. The discovery companion ([I-D.draft-mcguinness-mission-discovery]) defines the encounter contract, the identity pinning, and the floors the Person Server applies at that gate.¶

13. Conformance

An implementation conforms in one of two roles.¶

A Mission-Bound Person Server:¶

• maintains a Mission record for every approved mission, carried by the blob's native and flat members under the fixed equivalence of Section 4, and computes the integrity anchors as the projection of Section 4.1 with its issuer URL;¶

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

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

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

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

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

• declares which verification mode of Section 11 the deployment serves.¶

A Mission-Bound Agent:¶

• SHOULD propose a structured Mission Intent (Section 5);¶

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

14. Security Considerations

15. 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. The Subject's identity does not appear in the blob at all (Section 4), extending AAuth's directed-identity posture to the Mission artifact itself. 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 10).¶

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. 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 in the same way. 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.¶

16. 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: the flat mission_id, expires_at, and policy_version members (and the conditional mission_intent) 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.¶

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