Mission Open-World Discovery

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

Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the "issuance profile") commits a Mission's authority at the approval event, over resources the Authority Set names. An open-world agent breaks that premise: given a task, it meets resources, tools, and services the approval could not enumerate, and some substrates invert the ontology outright, with the resource declaring its own operations, meaning, and consequences at encounter time ([I-D.draft-hardt-aauth-r3]).¶

The family already routes the encounter through existing levers: a resource within a pre-consented ceiling binds by policy drawdown ([I-D.draft-mcguinness-oauth-mission-progressive]), a catalog capability binds through the capability-source binding ([I-D.draft-mcguinness-mission-capability-binding]), a partner domain binds through projection ([I-D.draft-mcguinness-oauth-mission-cross-domain]), and anything else requires a fresh approval ([I-D.draft-mcguinness-oauth-mission-expansion]). What no document defines is the encounter itself: what is submitted when an agent meets an unknown resource, who adjudicates it, what identity the resource must pin first, what its self-description may and may not influence, and what record survives. This document defines that contract, and the two floors that hold regardless of deployment policy: self-declarations never classify consequences, and tainted sessions never bind a newly discovered resource by policy alone.¶

2. Status: An Experimental Extension

This document is Experimental. It extends stable interfaces only through their declared seams: the progressive profile's drawdown path, the runtime profile's decision context, the AAuth binding's Person Server decision gate, and the evidence objects' coordinated-extension rules. A deployment that does not adopt it is unaffected; a Mission whose Authority Set and ceiling name every resource it touches never encounters this document. The stable path for a resource outside every envelope is a fresh human-approved expansion ([I-D.draft-mcguinness-oauth-mission-expansion]).¶

Maturity: experimental. Maintenance: lab-best-effort. Adopt when: An open-world agent meets resources its approval never named. Requires: Mission-Bound Runtime Enforcement; Mission Substrate Requirements. Also requires, conditionally: Mission-Aware Agent Harnesses (when the harness supplies taint state); Mission-Bound Authorization for OAuth 2.0 and Mission Progressive Authorization for OAuth 2.0 (when ceiling adjudication is the deployed mode).¶

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

• Mission, Authority Set, Mission Issuer, the subset rule, and the integrity anchors as the OAuth binding defines them, and imports the substrate's default commitment construction normatively ([I-D.draft-mcguinness-mission-substrate]): of the digests this document defines, resource_metadata_digest and resource_declaration_digest are raw-octet digests over exact retrieved bytes, and ceiling_entry_digest is a canonical-object digest over the entry drawn against;¶

• the authority ceiling, drawdown policy, and in-ceiling expansion as the progressive profile defines them ([I-D.draft-mcguinness-oauth-mission-progressive]);¶

• action classes, PEP, PDP, and the Enforcement Scope Statement as the runtime profile defines them ([I-D.draft-mcguinness-mission-runtime]);¶

• session taint as the harness profile defines it ([I-D.draft-mcguinness-mission-harness]);¶

• the Mission Authority Server (MAS) as [I-D.draft-mcguinness-mission-authority-server] defines it; and¶

• the Mission Deployment Profile, the deployment-level manifest the architecture defines ([I-D.draft-mcguinness-mission-architecture]).¶

It additionally uses:¶

Encounter:

The event of an agent meeting, during execution, a resource, capability catalog, or service that no entry of its Mission's consented ceiling names or, under contextual adjudication, for which the Mission's governance record holds no prior binding.¶

Discovery Adjudicator:

The component that decides an encounter. It is always the Mission Issuer: on the ceiling path, the issuer of the Mission; on the contextual path, the binding's Controller at its native decision gate, under the AAuth binding the Person Server ([I-D.draft-mcguinness-mission-aauth]). A binding creates authority, and authority is created only at the Mission Issuer; a PDP enforces bindings and refuses the unbound, and never adjudicates one.¶

Egress-capable:

Creating authority in the runtime profile's external-communication or external-commitment action classes.¶

Resource Self-Declaration:

A content-addressed statement a resource publishes about its own operations, meaning, and consequences. AAuth's Rich Resource Requests R3 document is one such form ([I-D.draft-hardt-aauth-r3]).¶

Discovery Binding:

The successful outcome of an adjudication: concrete authority for the encountered resource, within a consented ceiling entry, bound to the Mission.¶

4. Mission Substrate

This profile is defined against the Mission model rather than OAuth mechanics. Both adjudication modes (Section 7) consume the Mission record's committed members and the only-active rule.¶

Ceiling adjudication additionally consumes:¶

• the issuance profile's Authority Set representation with the subset rule's resource-narrowing semantics, the substrate's Structured Authority capability;¶

• the integrity-anchor envelope for the digests its evidence carries; and¶

• the progressive profile's consented ceiling, which is the only object a policy binding may draw against.¶

Contextual adjudication consumes the approved context and the ordered governance record in their place, and its evidence digests ride the binding's native commitment. It exists only where the binding's Controller natively adjudicates each governed request; the AAuth binding hosts it at the Person Server's decision gate ([I-D.draft-mcguinness-mission-aauth]).¶

5. The Encounter

An encounter is classified before it is adjudicated:¶

• A resource: an API origin or service the agent must call. It is adjudicated under this profile (Section 7).¶

• A capability catalog or tool: a tool server or catalog whose capabilities the agent would invoke. Its admission is adjudicated under this profile like any resource, through the Mission Issuer; the binding names the catalog and its admitted tool_id set, and each capability thereafter binds and drifts at the PDP under the capability-source rules ([I-D.draft-mcguinness-mission-capability-binding]).¶

• A foreign trust domain: a resource whose Authorization Server the deployment's trust does not cover. This profile does not bind it; cross-domain projection exists for domains with established trust ([I-D.draft-mcguinness-oauth-mission-cross-domain]), and everything else is a fresh approval. The encounter is still evidenced (Section 10): routed or refused, a foreign-domain encounter leaves the same record.¶

How the agent met the resource is not this document's subject. Discovery infrastructure, a capability registry with verified publisher namespaces, a federated catalog served from the publisher's own domain, or plain search, determines what an agent meets and what is known about it at encounter; it changes the encounter's quality, never its governance. An encounter sourced from a curated registry is classified and adjudicated like any other.¶

A deployment MAY scope a ceiling family to a registry or catalog it curates: membership then bounds what policy may bind, and every floor of this document applies within it unchanged.¶

The encounter request is agent-influenced input by construction: the agent chose what to meet, and content it ingested may have chosen for it. Every rule in this document is written against that fact, and no member of an encounter request derives, widens, or gates authority by itself, per the OAuth binding's inert-input rule.¶

6. Resource Identity

No binding occurs against an unpinned resource. The Mission Issuer MUST establish the identity of the encountered resource itself, from its own server-side retrieval. It MUST NOT accept any of the following agent-supplied values as that identity:¶

• an origin;¶

• a metadata digest;¶

• an issuer; or¶

• a declaration digest.¶

An Encountered Resource object that rides the agent's request is a hint the issuer verifies, never the pinned identity (Section 7). Before adjudication, the identity MUST be established and recorded:¶

1. Origin. The resource's origin, TLS-authenticated by the Mission Issuer's own connection at encounter, not as the agent reports it.¶

2. Authorization chain. Where the resource names an Authorization Server, the Mission Issuer MUST retrieve the OAuth 2.0 Protected Resource Metadata [RFC9728] server-side and digest the exact bytes it retrieved into the evidence. It MUST NOT reuse an agent-supplied digest. The Mission Issuer MUST verify that the named issuer is authorized for the resource's domain, for which the domain-authorized-issuer mechanism is one profile ([I-D.draft-mcguinness-oauth-domain-authorized-issuer]). Where it cannot, the encounter routes to a human and never binds by policy. Origin pinning ([RFC9728]) authenticates domain control, not the operator's trustworthiness or the resource-to-AS authorization: a party that controls a domain can publish metadata naming any issuer, so domain control alone is not authorization.¶

3. Self-declaration. Where the resource publishes a self-declaration, the Mission Issuer computes its content-addressed digest at encounter from the bytes it retrieved and carries that digest through adjudication and evidence (Section 8).¶

The two floors of this document (Section 8, Section 9) are only as strong as these issuer-verified inputs. An origin, digest, issuer, or taint state taken from the agent would let a prompt-injected agent fabricate identity or clear taint, so each MUST be established through a channel the agent does not mediate. Where the Mission Issuer cannot obtain a trustworthy identity, it MUST route the encounter to a human or refuse.¶

Where discovery infrastructure verified the publisher before the encounter, a namespace-verified registry entry or a catalog served from the publisher's own domain, that verification is an additional pinned fact: it strengthens the origin association, is recorded with the identity, and is rendered in any disclosure.¶

The pinned identity travels as one shape, the Encountered Resource object, on the wire and in evidence. When it rides the agent's request it is an unverified hint; the values recorded in evidence and used for adjudication are the Mission Issuer's own verified values (Section 6), never the agent's:¶

origin:

REQUIRED. A string containing a URI. The TLS-authenticated origin of the encountered resource.¶

resource_metadata_digest:

CONDITIONAL. REQUIRED when a protected-resource metadata document was retrieved: the integrity-anchor encoded digest of its exact retrieved bytes.¶

issuer:

CONDITIONAL. REQUIRED when the metadata names an Authorization Server: the issuer identifier it names.¶

In an AAuth deployment, the Person Server performs the equivalent pinning with native material: the Access Server association and, where the deployment adopts Rich Resource Requests, the R3 document's r3_s256 ([I-D.draft-hardt-aauth-r3], [I-D.draft-mcguinness-mission-aauth]).¶

7. Discovery Adjudication

An adjudication takes, at minimum:¶

• the Mission reference;¶

• the Encountered Resource object as the Mission Issuer verified it (Section 6);¶

• the self-declaration digest where one exists;¶

• the authority sought: the entry or entries a ceiling binding would create, or the governed request a contextual binding would permit, whose action classes under the deployment's classification drive every floor of this document;¶

• the requesting actor; and¶

• the session's taint state.¶

The taint state MUST be obtained from the harness through a channel the agent does not mediate (a harness attestation, [I-D.draft-mcguinness-mission-harness]), never from the encounter request. The adjudicator MUST treat a missing, stale, or unverifiable taint state as tainted: the floor of Section 9 keys on the harness's report, and an absent report is not an untainted one. An operation the deployment's classification cannot assign an action class MUST NOT bind by policy: with no class the floors cannot be applied, so the encounter routes to a human or is refused.¶

Adjudication runs in one of two modes, fixed by what the binding supplies (Section 4). Ceiling adjudication decides against a structured, pre-consented ceiling under the subset rule. Contextual adjudication is the Controller's own judgment that the encounter falls within the approved mission context, informed by the governance record and the person channel. Contextual adjudication is policy in this document's sense: the Controller's judgment is not the human's, and every floor of this document applies identically in both modes.¶

The adjudication returns exactly one of:¶

Bind.

In ceiling adjudication, the encountered resource falls within a consented ceiling entry under the subset rule's resource-narrowing semantics; in contextual adjudication, the Controller judges it within the approved mission context. No floor of this document objects, and concrete authority is created: under the OAuth binding, as a progressive in-ceiling drawdown whose successor entry names the resource ([I-D.draft-mcguinness-oauth-mission-progressive]); under the AAuth binding, as the Person Server's contextual decision at its gate, appended to the mission log with the pinned identity and declaration digest. A ceiling binding is narrowing-only: nothing an encounter creates may exceed the ceiling entry it draws against. A contextual binding is request-scoped: it creates no standing entry, and a later request is adjudicated again.¶

Route to a human.

The encounter is real but no policy may decide it:¶

• it falls outside every ceiling entry;¶

• a floor of this document requires a human (Section 8, Section 9); or¶

• identity could not be fully pinned.¶

The encounter becomes an expansion proposal carrying the pinned identity and declaration digest, so the Approver decides with the same facts the policy saw. The proposal travels the deployment's approval surface: the deferred-approval companion where deployed ([I-D.draft-mcguinness-oauth-mission-approval]), whose queue-pressure bounds apply to encounter-driven proposals unchanged, or the MAS's and Person Server's natively asynchronous approval otherwise. The disclosure renders:¶

• the Encountered Resource object;¶

• the declaration, as the resource's claim and not as fact; and¶

• the session's taint status.¶

The resulting approval or expansion evidence carries the encounter_id (Section 10), so the encounter and its human resolution correlate.¶

Refuse.

The encounter violates a hard rule (unpinnable identity the deployment does not escalate, a prohibited class, an exhausted bound) and is recorded as refused.¶

In ceiling adjudication, a Mission with no consented ceiling has no bind outcome: every encounter routes to a human or refuses. In contextual adjudication, an encounter the approved context cannot support routes the same way. Discovery is default-closed in both modes.¶

On the OAuth binding's drawdown path, the encounter rides the expansion request as two additional parameters, encountered_resource (the Encountered Resource object of Section 6) and resource_declaration_digest; the progressive profile's rate bound, prohibited-class mapping, and audit linkage apply to encounter-triggered drawdowns unchanged. A deployment MUST additionally bound the rate of encounter adjudications per Mission across all three outcomes. It MUST publish the concrete bound in the Mission Deployment Profile. Routed and refused encounters consume adjudicator and Approver attention, and are the probing surface of Section 12.¶

8. The Lying Resource

A self-declaration is self-asserted: a malicious resource declares itself read-only, reversible, and inconsequential, and authors consent text to match. A registry listing or publisher-verified catalog entry is a self-declaration in this sense: verification proves authorship, never safety. Therefore:¶

• A self-declaration is accountability material, never classification authority. The action classes of an encountered resource's operations are assigned by the deployment's own classification under the runtime profile ([I-D.draft-mcguinness-mission-runtime]), never taken from the declaration. A declaration MAY make classification stricter. It MUST NOT relax it.¶

• Authority in the irreversible, external-commitment, or privileged-administration classes MUST NOT bind on any encounter by policy alone, regardless of ceiling: those bindings route to a human, with the declaration rendered as the resource's claim, not as fact.¶

• The declaration digest is committed in evidence precisely so a lie is attributable: what the resource claimed at binding is reproducible against what it later did.¶

9. Injection-Driven Discovery

The sharpest open-world attack needs no authority excess: injected content steers the agent to encounter the attacker's resource and bind it in-ceiling, and the exfiltration channel is created rather than found. Discovery infrastructure sharpens the attack rather than blunting it: the attacker publishes a legitimately verified entry in a searchable index and injected content directs the agent to it, so every publisher check passes. Two rules close the policy path:¶

• In a session the harness reports tainted ([I-D.draft-mcguinness-mission-harness]), a request to a previously unknown origin is itself an egress channel, so every binding an encounter would create is egress-capable regardless of its operation class. Under taint, no encounter binds by policy: it routes to a human, and the disclosure states that the session had ingested untrusted content.¶

• A channel created by a discovery binding enters the harness's egress-channel enumeration at binding, recorded in Harness Evidence; an egress channel that did not enter through a binding or the original enumeration is a violation of the mediated environment, not a discovery.¶

Where the metering companion is deployed, a deployment MAY place discovered egress-capable bindings in an exclusivity group with its sensitive-read authority, so a session that has read cannot acquire new egress by encounter at all ([I-D.draft-mcguinness-mission-metering]).¶

The two floors compose to a simple matrix. External communication is the exfiltration leg, so an encounter binding that satisfies the external-communication predicate always routes to a human, as the progressive profile's prohibited set requires and this profile inherits unchanged ([I-D.draft-mcguinness-oauth-mission-progressive]). The irreversible, external-commitment, and privileged-administration classes are likewise never policy's to bind on any encounter. In an untainted session, policy may bind up to that floor. Taint removes every remaining class from policy's reach: under the first rule above, no encounter binds by policy and every binding routes to a human.¶

10. Discovery Evidence

Every adjudication, in all three outcomes, produces a Discovery Evidence object:¶

encounter_id:

REQUIRED. A string, unique per adjudication at this adjudicator. It correlates a routed encounter with the approval or expansion evidence that resolves it.¶

mission:

REQUIRED. An object: the Mission's id and issuer.¶

outcome:

REQUIRED. A string: bound, routed_to_approval, or refused.¶

resource:

REQUIRED. The Encountered Resource object of Section 6.¶

resource_declaration_digest:

CONDITIONAL. REQUIRED when a self-declaration existed at encounter: its content-addressed digest.¶

sought_classes:

REQUIRED. An array of strings: the action classes of the authority sought, under the deployment's classification (Section 8).¶

ceiling_entry_digest:

CONDITIONAL. REQUIRED on bound under ceiling adjudication: the integrity-anchor encoded digest of the ceiling entry drawn against. Absent for a contextual bind, whose record is the governance-record entry carrying the pinned identity and declaration digest.¶

actor:

REQUIRED. A string: the authenticated requesting actor.¶

tainted:

REQUIRED. A boolean: the session taint state the harness reported at adjudication.¶

adjudicated_at:

REQUIRED. An RFC 3339 [RFC3339] date-time.¶

The adjudicator signs the object under the suite's evidence conventions: a JWS whose protected header carries alg, a kid resolvable in the Mission Issuer's published key material, and a typ of mission-discovery-evidence+json (a local-use identifier pending registration; the value omits the application/ prefix, as JWS typ values do). The signature is what identifies the adjudicator, so the object carries no member for it. The payload's canonical bytes are its JCS canonicalization [RFC8785]. It is registrable in a transparency log on the Mission's feed ([I-D.draft-mcguinness-mission-audit]), and its members make an encounter reproducible: what was met, what it claimed, what was sought, what was drawn against, and under what taint.¶

An illustrative bound encounter (this Mission is not the one from the OAuth binding's walkthrough):¶

{
  "encounter_id": "enc_4Xq9Tr2Lm8vW",
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com"
  },
  "outcome": "bound",
  "resource": {
    "origin": "https://api.vendor.example",
    "resource_metadata_digest":
      "sha-256:mK4wZ7rQ2nX9bV5tY8cD1eF6gH3jL0pS4uA7iE2oN9M",
    "issuer": "https://auth.vendor.example"
  },
  "resource_declaration_digest":
    "sha-256:pV2nR8kQ4mZ7tX1cF5gH9jL3bD6eY0wS8uA2iE4oN7q",
  "sought_classes": ["data_read"],
  "ceiling_entry_digest":
    "sha-256:tY8cD1eF6gH3jL0pS4uA7iE2oN9MmK4wZ7rQ2nX9bV5",
  "actor": "s6BhdRkqt3",
  "tainted": false,
  "adjudicated_at": "2026-07-08T15:04:05Z"
}

A deployment adopting Mission Containment ([I-D.draft-mcguinness-oauth-mission-containment]) may configure its containment policy to treat a routed_to_approval outcome of this section, or a Discovery Evidence record carrying tainted true, as a protected event. Neither field alone determines the event: this document defines the outcome and the evidence it produces, not the policy that consumes them into a containment trigger.¶

11. Conformance

A deployment claiming this profile MUST:¶

• adjudicate every encounter of the classes it enables through Section 7, default-closed, establishing resource identity itself and independently of the agent, with the pinning of Section 6;¶

• obtain the session taint state through a channel the agent does not mediate, and treat an untrustworthy taint state as tainted (Section 7);¶

• route to a human or refuse any encounter it cannot pin, cannot classify, or cannot obtain a trustworthy taint state for (Section 6, Section 7);¶

• enforce both floors: no consequence classification from self-declarations, with the high-consequence human floor (Section 8); and no policy binding of egress-capable authority in tainted sessions (Section 9);¶

• bound the rate of encounter adjudications per Mission across all outcomes and publish the concrete bound in the Mission Deployment Profile (Section 7);¶

• produce and sign Discovery Evidence for every adjudication, foreign-domain encounters included (Section 10); and¶

• state in its Enforcement Scope Statement which encounter classes it adjudicates, the ceiling families consented for them, and the floors as published limits.¶

12. Security Considerations

The lying resource is Section 8's subject; its residual is honest: a resource whose operations are correctly classified low-consequence can still misdescribe its meaning to an Approver, and the declaration digest makes that attributable, not impossible.¶

Injection-driven discovery is Section 9's subject; its residual is an untainted session binding within an over-broad consented family. The mitigation is at consent time: ceiling families SHOULD be as narrow as the task allows, and the progressive profile's rate bound applies per chain, so mass encounter-binding is bounded and visible.¶

Declaration swap. A resource that changes its declaration between encounter and use is caught by the digest: the runtime capability-drift rule refuses catalog capabilities whose source changed, and a re-encountered resource whose declaration digest differs is a new encounter, not a bound one.¶

Probing. The outcome trichotomy itself leaks coarse ceiling shape to whoever controls what the agent meets: bind, route, and refuse partition the world. Refusals are uniform (refused carries no ceiling detail), the adjudication rate bound of Section 7 prices the probe, a deployment MAY collapse refused into routed_to_approval so a probe sees a single non-bind outcome while a human sees the pattern, and the anti-oracle discipline of the family's status surfaces applies to any encounter-facing endpoint.¶

Adjudicator availability. The adjudicator sits on the discovery path only: a bound resource is thereafter enforced by the runtime layer without re-adjudication, and adjudicator outage stops new bindings, never existing authority. Fail-closed here costs opportunity, not work in flight.¶

13. Privacy Considerations

Encounters reveal where an agent goes: the adjudicator learns every resource an agent met, including refused ones, and the transparency log, which receives only hash commitments ([I-D.draft-mcguinness-mission-audit]), still learns the Mission's feed, its registration cadence, and that encounters occurred. That trail is the point for audit, and a hazard for the Subject. A deployment minimizes by restricting Discovery Evidence access as it does other Mission evidence and applying the issuance profile's identifier guidance where correlation across feeds matters. A self-declaration may itself contain third-party information; the digest commitment keeps that content out of the log.¶

14. IANA Considerations

This document makes no IANA request. The evidence type identifier of Section 10 is local-use pending registration.¶

15. References

Acknowledgments

This document gives the family's open-world encounter one contract and two floors; the mechanisms it composes are the progressive, runtime, harness, and audit profiles' own.¶

Author's Address