Network Working Group K. McGuinness Internet-Draft Independent Intended status: Experimental 8 July 2026 Expires: 9 January 2027 Mission Open-World Discovery draft-mcguinness-mission-discovery-latest Abstract A Mission commits its authority at approval, but an open-world agent meets resources the approval could not name. This document defines discovery as a governed operation: the Encounter, the Discovery Adjudication that evaluates a newly met resource against a pre- consented ceiling, the identity a discovered resource must pin before any binding, and the Discovery Evidence that makes each binding reproducible in audit. Two floors hold regardless of policy: a resource's self-declaration is accountability material and never classification authority, and in a session that has ingested untrusted content no external-communication- or commitment-capable resource binds without a human. A Mission without a ceiling binds nothing discovered: the open world is reachable only through consent given in advance, narrowed at every step, and evidenced at every binding. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mcguinness.github.io/mission-bound-authorization/draft- mcguinness-mission-discovery.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- mcguinness-mission-discovery/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/mission-bound-authorization. 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 9 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 2. Status: An EXPERIMENTAL Extension 2.1. Requirements Language 3. Conventions and Terminology 4. Mission Substrate 5. The Encounter 6. Resource Identity 7. Discovery Adjudication 7.1. Re-Encounter and Drift 8. The Lying Resource 9. Injection-Driven Discovery 10. Discovery Evidence 11. Conformance 12. Security Considerations 13. Privacy Considerations 14. IANA Considerations 15. References 15.1. Normative References 15.2. Informative References Acknowledgments Author's Address 1. Introduction Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the "issuance profile", here "the core") 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-authzen]), 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 egress 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, 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]). 2.1. Requirements Language 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. 3. Conventions and Terminology This document uses Mission, Authority Set, Mission Issuer, the subset rule, and the integrity anchors as the core defines them; 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, and PDP as the runtime profile defines them ([I-D.draft-mcguinness-mission-runtime]); and session taint as the harness profile defines it ([I-D.draft-mcguinness-mission-harness]). 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 Authority Set names. Discovery Adjudicator: The component that decides an encounter. It is always the Mission Issuer: the issuer of the Mission on the drawdown path, or the AAuth Person Server at its token gate ([I-D.draft-mcguinness-mission-aauth]), which is that binding's Mission Issuer. 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. It consumes: the Mission record's committed members and the only-active rule; the Authority Set representation with the subset rule's resource-narrowing semantics; the integrity-anchor envelope for the digests its evidence carries; and the progressive profile's consented ceiling, which is the only object a discovery binding may draw against. Where these exist under another binding, this profile composes unchanged; the AAuth binding hosts the adjudication at its Person Server token gate. 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-authzen]). * *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. 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 core's inert-input rule. 6. Resource Identity No binding occurs against an unpinned resource. Before adjudication, the identity of the encountered resource MUST be established and recorded: 1. *Origin.* The resource's origin, TLS-authenticated at encounter. 2. *Authorization chain.* Where the resource names an Authorization Server, the resource-to-AS association is established through OAuth 2.0 Protected Resource Metadata [RFC9728], and the metadata document's bytes are digested into the evidence. A deployment SHOULD additionally 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]); an unverifiable issuer association routes the encounter to a human. 3. *Self-declaration.* Where the resource publishes a self- declaration, its content-addressed digest is computed at encounter and carried through adjudication and evidence (Section 8). The pinned identity travels as one shape, the *Encountered Resource object*, on the wire and in evidence: 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. Under the AAuth binding, the Person Server performs the equivalent pinning with the substrate's own material: the Access Server association and the R3 document's r3_s256 ([I-D.draft-mcguinness-mission-aauth]). 7. Discovery Adjudication An adjudication takes, at minimum: the Mission reference; the Encountered Resource object (Section 6); the self-declaration digest where one exists; the authority sought, the entry or entries the binding would create, whose action classes under the deployment's classification drive every floor of this document; the requesting actor; and the session's taint state as the harness reports it. It returns exactly one of: *Bind.* The encountered resource falls within a consented ceiling entry under the subset rule's resource-narrowing semantics, no floor of this document objects, and concrete authority is created for it: 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 token-gate decision. The binding is narrowing-only: nothing an encounter creates may exceed the ceiling entry it draws against. *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. A Mission with no consented ceiling has no bind outcome: every encounter routes to a human or refuses. Discovery is default-closed. 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: routed and refused encounters consume adjudicator and Approver attention, and are the probing surface of Section 12. 7.1. Re-Encounter and Drift A binding persists as the authority it created. An encounter whose Encountered Resource object matches an existing entry, its origin within the entry's resource and its declaration digest equal to the one recorded for that binding, is not a new encounter: no adjudication runs, no drawdown is spent, and the runtime layer enforces as usual. An encounter whose declaration digest differs from the recorded one is a new encounter for any authority not yet bound, and a drift signal for what is: a deployment SHOULD re- adjudicate a bound resource whose declaration changed before further use in a consequential class, and the capability-source rules already refuse drifted catalog capabilities at the PDP ([I-D.draft-mcguinness-mission-authzen]). 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. 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 only make classification stricter, never laxer. * 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. Two rules close the policy path: * In a session the harness reports tainted ([I-D.draft-mcguinness-mission-harness]), an encounter whose binding would create external-communication- or external- commitment-capable authority MUST NOT bind 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: in an untainted session, policy may bind up to the high-consequence floor, external communication included; taint removes external communication from policy's reach; and the irreversible, external-commitment, and privileged-administration classes are never policy's to bind on any encounter. 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: the integrity-anchor encoded digest of the ceiling entry drawn against. 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 application/mission-discovery-evidence+json (a local-use identifier pending registration); 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 core walkthrough's): { "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" } 11. Conformance A deployment claiming this profile: * adjudicates every encounter of the classes it enables through Section 7, default-closed, with the identity pinning of Section 6; * enforces 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); * bounds the rate of encounter adjudications per Mission across all outcomes (Section 7); * produces and signs Discovery Evidence for every adjudication, foreign-domain encounters included (Section 10); and * states 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, and the transparency log where evidence registers, learn every resource an agent met, including refused ones. That trail is the point for audit, and a hazard for the Subject. A deployment minimizes by registering digests rather than declarations, 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; committing its digest rather than its bytes 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 15.1. Normative References [I-D.draft-mcguinness-mission-harness] McGuinness, K., "Mission-Aware Agent Harnesses", 2026, . [I-D.draft-mcguinness-mission-runtime] McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, . [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-progressive] McGuinness, K., "Mission Progressive Authorization for OAuth 2.0", 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, . 15.2. Informative References [I-D.draft-hardt-aauth-r3] Hardt, D., "AAuth Rich Resource Requests (R3)", 2026, . [I-D.draft-mcguinness-mission-aauth] McGuinness, K., "Mission-Bound Authorization for AAuth", 2026, . [I-D.draft-mcguinness-mission-architecture] McGuinness, K., "An Architecture for Mission-Bound Authorization", 2026, . [I-D.draft-mcguinness-mission-audit] McGuinness, K., "Mission Audit Transparency", 2026, . [I-D.draft-mcguinness-mission-authzen] McGuinness, K., "Mission-Bound Runtime Enforcement: AuthZEN Profile", 2026, . [I-D.draft-mcguinness-mission-metering] McGuinness, K., "Mission Consumption Metering", 2026, . [I-D.draft-mcguinness-oauth-domain-authorized-issuer] McGuinness, K., "OAuth Domain-Authorized Issuer Trust Method", Work in Progress, Internet-Draft, draft- mcguinness-oauth-domain-authorized-issuer-00, 5 July 2026, . [I-D.draft-mcguinness-oauth-mission-approval] McGuinness, K., "Mission Deferred Approval for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-cross-domain] McGuinness, K., "Mission Cross-Domain Projection for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-expansion] McGuinness, K., "Mission Expansion for OAuth 2.0", 2026, . 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 Karl McGuinness Independent Email: public@karlmcguinness.com