Mission Capability Binding

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 23 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

An agent's approved authority can name a capability, an MCP tool, an OpenAPI operation, or a catalog entry, rather than a fixed action name. The catalog a Mission was approved against is not immutable: a tool's definition can change, a catalog can be revised, or an invoked identity can drift from the one the approval bound. Without a binding back to the capability source, a Policy Decision Point (PDP) enforcing the runtime profile's decision contract [I-D.draft-mcguinness-mission-runtime] has no way to tell a stable capability from one that has silently mutated underneath the approval.¶

This document is a companion to Mission-Bound Runtime Enforcement: AuthZEN Profile [I-D.draft-mcguinness-mission-authzen] (the "AuthZEN binding"). It defines the capability-source binding a validating server records at derivation and a Policy Enforcement Point (PEP) presents at decision time in context.capability_source of the OpenID AuthZEN Authorization API [AUTHZEN] request the AuthZEN binding shapes: a stable tool_id, the discovery source_uri, a source_digest over the capability's extracted definition, and an operation_ref. It defines the per-capability extraction rule that computes source_digest, the decision-time verification a PDP performs, the capability_drift denial reason this document registers as a coordinated extension of the AuthZEN binding's runtime denial classification, and the mapping onto the AuthZEN Profile for Model Context Protocol Tool Authorization (COAZ) [COAZ] for MCP deployments.¶

This document rides the AuthZEN binding's request as context.capability_source and the runtime profile's capability identity requirement; it defines no drift rule of its own, since that requirement is the runtime profile's ([I-D.draft-mcguinness-mission-runtime]). A deployment that does not claim this companion is unaffected: the AuthZEN binding's decision contract consumes an already established action identity.¶

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

This document uses JSON [RFC8259] as the data model for the capability-source binding object. JCS canonicalization [RFC8785] applies wherever this document computes a digest, under the substrate's default commitment construction ([I-D.draft-mcguinness-mission-substrate]); this document does not define a second canonicalization.¶

"SHA-256" refers to [RFC6234]. A digest is encoded in the encoded form of the substrate's default commitment construction ([I-D.draft-mcguinness-mission-substrate]): sha-256: followed by the base64url, no-padding encoding of the digest. Under the substrate's default commitment construction, which this document imports normatively ([I-D.draft-mcguinness-mission-substrate]), source_digest is a canonical-object digest and catalog_digest a raw-octet digest over the exact retrieved representation.¶

The terms Policy Enforcement Point (PEP), Policy Decision Point (PDP), consequential action, and Executor are used as defined in [I-D.draft-mcguinness-mission-runtime]. The AuthZEN request and response envelope, the context object, and the runtime denial classification are used as defined in [I-D.draft-mcguinness-mission-authzen].¶

Validating server:

The component that, at derivation, validates the Mission's authority and records the derivation-time facts a PDP later checks, such as a capability source_digest (Section 4). In the issuance profile this is the Mission Issuer; this document uses the term where the recording role is what matters.¶

3. Capability Source Context

For catalog-sourced actions, the PEP supplies the capability-source binding in context.capability_source using the object defined in Section 4. For non-catalog actions, this member is absent.¶

4. Capability Source Binding

Consequential actions an agent discovers at runtime, through a Model Context Protocol tool catalog, an OpenAPI document, a Protected Resource Metadata-linked catalog, or an equivalent capability source, identify the source they came from, so a Mission's approved authority stays bound to concrete tools rather than to bare action names a later catalog revision could redefine. The runtime profile assigns capability identity to the approved actions and refuses an invoked identity outside them ([I-D.draft-mcguinness-mission-runtime]); this document gives the concrete binding an AuthZEN deployment presents for catalog-sourced actions.¶

For MCP tools, this binding composes with the AuthZEN MCP profile's COAZ mapping [COAZ]. COAZ maps MCP tool definitions and invocation parameters into the AuthZEN Subject-Action-Resource-Context model; this document adds Mission governance, source binding, Mission evidence, and runtime metering. A Mission-governed MCP deployment MAY use COAZ to construct the AuthZEN subject, resource, action, and parameter-bearing context members, but the Mission-specific context.mission, context.actor, freshness, permit binding, and evidence requirements of the AuthZEN binding ([I-D.draft-mcguinness-mission-authzen]) still apply.¶

The minimum binding, committed by the validating server at derivation and presented by the executing component at request time in context.capability_source, is:¶

{
  "tool_id": "mcp://docs.example.com/tools/write_document",
  "source_uri": "https://docs.example.com/.well-known/mcp",
  "source_digest":
    "sha-256:OAbEIh2DTYUVP7DjRhHct4aapsT8PybZq2ILdut9UP0",
  "operation_ref": "tools/write_document"
}

tool_id:

A string. A stable capability identifier the executing component asserts the action invokes.¶

source_uri:

A string. The discovery source the capability was resolved from.¶

source_digest:

A string. The integrity-anchor encoded form ([I-D.draft-mcguinness-oauth-mission]) over the capability's extracted definition (Section 4.2), recorded at derivation time. At request time it is computed over the current extracted definition, so the PDP's comparison detects a mutated definition.¶

operation_ref:

A string. The source-format-specific operation reference (MCP tool name, OpenAPI operationId, or equivalent).¶

catalog_digest:

OPTIONAL. A string. The integrity-anchor encoded form over the exact retrieved source representation, recorded at derivation time. Its semantics are strictly stricter than source_digest: when recorded, any change to the retrieved source refuses, whether or not it touches the capability. A deployment records it where the whole catalog is the trust unit.¶

executor:

OPTIONAL. A string. An identifier for the executing component that serves the capability at request time (for example, an MCP server instance), asserted by the PEP that authenticates it. It is a request-time fact, not part of the derived authority recorded at derivation, and is recorded in Decision Evidence when present; it is never an input to the source_digest or catalog_digest comparison. Where the executing component authenticates under an attested-instance profile ([I-D.draft-mcguinness-oauth-client-instance-assertion], [I-D.draft-mcguinness-oauth-ai-agent-instance]), the deployment SHOULD carry the attested instance identifier here rather than a self-chosen label.¶

Rules:¶

• The validating server records tool_id, source_uri, source_digest, operation_ref, and any catalog_digest for every consequential action sourced from a discovered catalog. These values are part of the approved Mission's derived authority and are therefore covered by authority_hash ([I-D.draft-mcguinness-oauth-mission]).¶

• The PEP presents tool_id on consequential requests for catalog-sourced actions. The runtime profile owns the drift semantics ([I-D.draft-mcguinness-mission-runtime]); the PDP applies them through this document's decision-time verification (Section 4.1), over the per-capability comparison scope of Section 4.2. This document adds only the wire representation and per-capability verification: such a refusal is carried as capability_drift (Section 4.3), with its boundary against out_of_authority fixed by the AuthZEN binding's runtime denial classification ([I-D.draft-mcguinness-mission-authzen]). It defines no drift rule of its own.¶

• Resource policy MAY refuse a catalog-sourced action whose source_uri or executor is outside the deployment's trusted set. Such a refusal is a Resource-policy condition, carried as resource_policy ([I-D.draft-mcguinness-mission-authzen]), not a drift refusal.¶

• Actions not sourced from a discovered catalog (deployment-registered authorization_details types, first-party operations with stable identity) do not require this binding.¶

{
  "name": "write_document",
  "description": "Create or update a document",
  "inputSchema": {
    "type": "object",
    "properties": {
      "path": { "type": "string" },
      "content": { "type": "string" }
    },
    "required": ["path", "content"]
  }
}

{"description":"Create or update a document","inputSchema":{"propert
ies":{"content":{"type":"string"},"path":{"type":"string"}},"require
d":["path","content"],"type":"object"},"name":"write_document"}

source_digest = sha-256:OAbEIh2DTYUVP7DjRhHct4aapsT8PybZq2ILdut9UP0

5. Conformance

A deployment claims Mission Capability Binding only for the catalog-sourced actions within the runtime enforcement scope it documents ([I-D.draft-mcguinness-mission-runtime]), under the AuthZEN decision-API binding ([I-D.draft-mcguinness-mission-authzen]).¶

A validating server conforming to this document MUST record tool_id, source_uri, source_digest, operation_ref, and any catalog_digest for every consequential action sourced from a discovered catalog, at derivation (Section 4).¶

A PEP conforming to this document MUST present context.capability_source on a consequential request for a catalog-sourced action (Section 3).¶

A PDP conforming to this document MUST verify the presented binding against the recorded one and return capability_drift on a mismatch (Section 4.1, Section 4.3).¶

A deployment that does not claim this document is unaffected: the AuthZEN binding's decision contract consumes an already established action identity ([I-D.draft-mcguinness-mission-authzen]).¶

6. Security Considerations

The runtime profile's Security Considerations ([I-D.draft-mcguinness-mission-runtime]) and the AuthZEN binding's ([I-D.draft-mcguinness-mission-authzen]) apply in full. This section addresses only threats specific to capability-source binding.¶

7. Privacy Considerations

The runtime profile's evidence-privacy guidance ([I-D.draft-mcguinness-mission-runtime]) applies in full. source_uri, tool_id, and executor, when recorded in Decision Evidence ([I-D.draft-mcguinness-mission-runtime-evidence]), MAY reveal internal catalog topology; this document defines no additional record content and no exemption from that guidance.¶

8. IANA Considerations

This document requests no IANA actions. The context.capability_source member this document adds to the AuthZEN request context object ([I-D.draft-mcguinness-mission-authzen]) is AuthZEN extension data and is not registered in an IETF registry. The capability_drift denial-reason value is a specification-coordinated extension of the runtime denial classification ([I-D.draft-mcguinness-mission-authzen]), not an IANA-registered value.¶

9. References

Acknowledgments

This document extracts the capability-source binding from Mission-Bound Runtime Enforcement: AuthZEN Profile and builds on the OpenID AuthZEN Profile for Model Context Protocol Tool Authorization. The author thanks the OpenID AuthZEN community and the Mission-Bound Authorization implementer community for feedback.¶

Author's Address