| Internet-Draft | OAuth Mission Submission Evidence | October 2026 |
| McGuinness | Expires 7 April 2027 | [Page] |
Mission-Bound Authorization for OAuth 2.0 lets a client present Intent Submission Evidence alongside a submitted Mission Intent. The authorization server refuses any entry it cannot verify and treats a verified entry as policy input, never authority. This document defines the framework that evidence types and authorization servers share: the entry convention an evidence type follows, resolution of required evidence before derivation, binding of evidence to one exact Mission Intent and to the presenter the containing exchange establishes, a bound on verification cost, where the error is returned, and the place of presented evidence in a Mission-creation idempotency fingerprint. It defines no evidence types.¶
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-oauth-mission-submission-evidence.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mcguinness-oauth-mission-submission-evidence/.¶
Source for this draft and an issue tracker can be found at https://github.com/mcguinness/mission-bound-authorization.¶
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 7 April 2027.¶
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.¶
Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the OAuth binding) carries Intent Submission Evidence in the Submission envelope, refuses an entry it cannot verify, and treats a verified entry as policy input. This document adds the rest of the evidence framework: how an evidence type is specified, when evidence is required, what verified evidence binds, how much verification a submission can demand, and where the error is returned.¶
The framework uses these seams of the OAuth binding and changes none of its rules:¶
the Submission envelope's optional evidence member, with its size
and count bounds ([I-D.draft-mcguinness-oauth-mission], Section
"Submission via PAR");¶
the "reject, do not ignore" and "policy input, not authority" rules ([I-D.draft-mcguinness-oauth-mission], Section "Intent Submission Evidence");¶
the invalid_mission_intent_evidence error code, which the OAuth
binding registers ([I-D.draft-mcguinness-oauth-mission], Section
"OAuth Extensions Error Registration"); and¶
the Mission Record's submission_evidence member, which records
the verified facts ([I-D.draft-mcguinness-oauth-mission], Section
"Mission Record").¶
This document defines no evidence types. A companion profile defines each type under the convention of Section 3.¶
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 the terms Mission, Mission Intent, Submission
envelope, Intent Submission Evidence, Mission Record, Mission Issuer
(the "AS"), approval event, Authority Set, and intent_hash from
[I-D.draft-mcguinness-oauth-mission].¶
Each entry is a JSON object with a REQUIRED type member: a string
naming the evidence type as a collision-resistant name, under the
same guidance as anchor typ values
([I-D.draft-mcguinness-oauth-mission], Section "Integrity
Anchors"). The specification that owns a type defines the entry's
remaining members as a closed schema, the artifact format, the
verification procedure, and the verified output facts that
verification yields.¶
This document defines no generic member other than type, and no
evidence types; an AS that supports no evidence type refuses every
presented entry under the OAuth binding's dispatch rule
([I-D.draft-mcguinness-oauth-mission], Section "Intent Submission
Evidence").¶
These rules apply alongside the OAuth binding's "reject, do not
ignore" and "policy input, not authority" rules
([I-D.draft-mcguinness-oauth-mission], Section "Intent Submission
Evidence"), on every surface that carries the Submission envelope:
PAR, and each carriage a companion profile defines. They apply to
every submission, including one that carries no evidence member.¶
The AS determines the evidence types its applicable profile, client,
resource, or admission policy requires before derivation. When a
required type is absent from the submission, the AS MUST refuse the
submission with the invalid_mission_intent_evidence error code.
This is the submission-plane form of the downgrade rules of the OAuth
binding ([I-D.draft-mcguinness-oauth-mission], Section "Authority
Proposal").¶
The owning evidence type's specification defines how intent-bound
evidence identifies its intended AS and how that binding is verified.
The AS MUST refuse an intent-bound entry that does not verifiably
identify this AS, with invalid_mission_intent_evidence. This includes
an absent binding or a binding to a different AS.¶
Before derivation, the AS verifies that intent-bound evidence is
bound to this AS, names exactly the provisional intent_hash
computed from the submitted Intent, and agrees with the presenter
established by the containing exchange (Section 4.3).¶
Evidence bound to an intent_hash applies only to that exact
semantic Intent. When a shaping
([I-D.draft-mcguinness-mission-shaping]) or approval revision
([I-D.draft-mcguinness-oauth-mission-approval-revision]) changes
intent_hash, the AS MUST NOT treat evidence bound to the
predecessor Intent as evidence for the revised Intent, unless the
evidence type's specification explicitly authorizes that
transformation and defines how its lineage is verified.¶
The AS establishes the presenter through the containing exchange:
client authentication and, where present, proof of possession. An
entry that names an authorized presenter (a client_id, a cnf key
binding [RFC7800]) MUST match the established presenter, and a
mismatch fails
that entry's verification. Evidence is never an alternative
client-authentication mechanism and never selects the presenter.¶
Beyond the size and count bounds of the OAuth binding
([I-D.draft-mcguinness-oauth-mission], Section "Submission via
PAR"), the AS MUST bound the verification cost a submission can
impose (for example, the number of signature verifications it
performs), refusing a submission that exceeds the bound with the
invalid_request error code.¶
The AS returns the invalid_mission_intent_evidence error code where
the containing exchange returns its errors: in the PAR error response
(Section 2.3 of [RFC9126]) for a PAR submission, and in the token
error response (Section 5.2 of [RFC6749]) for a token-endpoint
carriage that a companion profile defines.¶
On a surface that carries a Mission-creation idempotency fingerprint (the expansion and child-creation token exchanges, [I-D.draft-mcguinness-oauth-mission-expansion], [I-D.draft-mcguinness-oauth-mission-child-delegation]), presented evidence is a member of that fingerprint, which the owning profile lists. Recovery of a completed operation on those surfaces returns the recorded outcome without re-verifying the presented evidence, even when an artifact's freshness or status has since lapsed. PAR-based creation and surfaces that submit no Mission Intent carry no such fingerprint and keep their own replay and idempotency mechanisms.¶
An AS conforming to this document implements the OAuth binding's Intent Submission Evidence rules ([I-D.draft-mcguinness-oauth-mission], Section "Intent Submission Evidence") and MUST implement:¶
required-evidence resolution (Section 4.1);¶
Intent binding (Section 4.2);¶
presenter agreement (Section 4.3); and¶
the verification bound (Section 4.4).¶
It returns errors as Section 5 describes and, on a surface that carries a Mission-creation idempotency fingerprint, treats presented evidence as Section 6 describes.¶
A specification that defines an evidence type follows the entry convention (Section 3). An AS that supports an evidence type conforms to this document.¶
Verified evidence is not copied into the Authority Set, and the facts
the Mission Record retains are not carried on the mission claim
([I-D.draft-mcguinness-oauth-mission], Section "Mission Record"). A
Resource Server does not need to understand this document.¶
The security considerations of the OAuth binding apply ([I-D.draft-mcguinness-oauth-mission], Section "Security Considerations").¶
Stripping a required entry from a submission is a downgrade attempt. Resolving required types before derivation (Section 4.1) turns the omission into a refusal rather than an admission on weaker evidence.¶
An admission or consent decision covers the Intent it was made for.
Carrying it to a revised Intent would apply it to a task it never
covered; Section 4.2 confines it to one intent_hash.¶
An evidence artifact is not a credential. Because the containing exchange establishes the presenter (Section 4.3), a stolen artifact neither authenticates its holder nor lets a different client present it as the named presenter.¶
An entry can demand signature verification, status retrieval, or other work. Without a bound, a small submission could impose a large cost on the AS; Section 4.4 refuses such a submission.¶
An evidence artifact can carry personal data, such as an originator identity or a consent reference. The OAuth binding keeps it off the front channel through PAR and governs access to the facts the Mission Record retains ([I-D.draft-mcguinness-oauth-mission], Section "Mission Record and Evidence Access"). An evidence type's specification controls that exposure through the verified output facts it designates for recording.¶
This document has no IANA actions. The
invalid_mission_intent_evidence error code it uses is registered by
the OAuth binding ([I-D.draft-mcguinness-oauth-mission], Section
"OAuth Extensions Error Registration").¶
[[ To be removed from the final specification ]]¶
-00¶
Clarified the boundary with the OAuth binding: the framework owns
the pre-derivation checks on intent-bound evidence, including its
AS, exact-Intent, and presenter binding. An intent-bound entry whose
intended-AS binding is absent, invalid, or identifies another AS is
refused with invalid_mission_intent_evidence; its evidence type
defines how the binding is expressed and verified. The OAuth binding
keeps its evidence dispatch and refusal rules and permits an AS that
supports no evidence types.¶
Initial version. Carries the Intent Submission Evidence framework of
Mission-Bound Authorization for OAuth 2.0 with its wire names and
rules unchanged: the entry convention, required-evidence resolution,
binding to one exact Intent, presenter agreement, the verification
bound, error placement, and the creation-fingerprint note. The OAuth
binding keeps the evidence member and its bounds, the reject and
policy-input rules, the invalid_mission_intent_evidence
registration, and the submission_evidence record member.¶