Mission Consent Evidence for OAuth 2.0

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 26 December 2026.¶

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") binds a Mission to an approval event and commits two objects: the approved Mission Intent and the approved Authority Set. It deliberately notes a remaining gap: the exact consent disclosure rendered to the Approver is not itself committed. A faulty or malicious rendering layer could show a narrower task than the Authority Set actually records.¶

This document narrows that gap. It defines a structured consent disclosure object and a Consent Evidence object. The disclosure object is what the Authorization Server renders or commits to rendering. The evidence object records the approval event, the rendering context, the Mission anchors, and an integrity envelope over the evidence.¶

This profile commits the structured disclosure that the Authorization Server says it rendered, and binds it to the same Mission anchors used for authority. It does not, and cannot, prove that the pixels actually presented to the Approver matched that structured object, that the Approver read or understood it, or that the rendering layer was honest. A faulty or malicious rendering layer that lies about what it displayed remains outside the reach of any server-side commitment. What this profile provides is a durable, integrity-protected record that ties a specific structured disclosure to a specific approval decision and Authority Set, so that divergence between the recorded disclosure and the enforced authority becomes detectable in audit.¶

How much a deployment can narrow the rendering gap is not all-or-nothing. This profile defines a ladder of rendering assurance (Section 6) whose rungs move the trust from an unbounded, unverifiable rendering layer toward the Approver's own authenticator signing the exact disclosure commitment. No rung proves what pixels a human perceived, but the higher rungs shrink the trusted rendering base to a small, attestable one and let the deployment pick the assurance its threat model needs.¶

Consent Evidence does not grant authority. Authority remains the approved Mission and its Authority Set under [I-D.draft-mcguinness-oauth-mission]. Consent Evidence lets auditors verify that the recorded approval surface corresponded to the authority later enforced.¶

2. Scope

This document defines:¶

• the consent disclosure object (Section 4);¶

• the consent_rendering_hash commitment (Section 5);¶

• the Consent Evidence object (Section 7);¶

• binding rules for initial Mission approval and expansion approval (Section 8);¶

• retention and audit reconstruction requirements (Section 9); and¶

• conformance for a Consent-Evidence-capable Mission Issuer (Section 10).¶

This document does not define user-interface layout, a legal consent standard, or any new OAuth grant. It does not change the Authority Set or Mission lifecycle.¶

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 JSON [RFC8259] for the disclosure and evidence objects. JCS [RFC8785] is used when computing consent_rendering_hash.¶

The terms Mission, Mission Intent, Authority Set, Mission Issuer, Approver, and approval event are used as defined in [I-D.draft-mcguinness-oauth-mission].¶

Consent Disclosure:

A structured object describing the approval surface rendered to the Approver.¶

Consent Evidence:

A durable, integrity-protected record of the consent disclosure and approval event.¶

4. Consent Disclosure Object

A Consent Disclosure object has these members:¶

disclosure_id:

REQUIRED. A string. Unique identifier for this rendered disclosure.¶

template_id:

REQUIRED. A string identifying the disclosure template.¶

template_version:

REQUIRED. A string identifying the template version.¶

locale:

REQUIRED. A string identifying the locale used for presentation.¶

mission_summary:

REQUIRED. An object. The human-readable task summary presented to the Approver.¶

authority_summary:

REQUIRED. An object. The rendered summary of resources, actions, constraints, delegation, expiry, and material consumption bounds.¶

material_notices:

REQUIRED. An array. Notices that materially affect the Approver's decision, such as irreversible actions, external commitments, privileged administration, cross-domain disclosure, broad reads, or delegation.¶

risk_summary:

REQUIRED. An object summarizing action classes and risk dimensions presented to the Approver. It MUST identify at least irreversible actions, external commitments, privileged administration, broad or bulk reads, cross-domain disclosure, delegation, and consumption bounds when present.¶

delegation_summary:

REQUIRED when the Authority Set permits delegation. An object describing who may receive delegated authority, maximum depth, and whether child Missions or further delegation are permitted.¶

runtime_summary:

OPTIONAL. An object describing runtime enforcement expectations shown to the Approver, such as per-action checks, status freshness, audit evidence, or human-review steps.¶

subject:

REQUIRED when the Approver is not the Subject. The rendered identification of the Subject on whose behalf authority is granted.¶

approver:

REQUIRED. The rendered identity of the Approver.¶

source_hashes:

REQUIRED. An object containing the intent_hash and authority_hash values the disclosure corresponds to. The disclosure object carries these two hashes rather than the full mission container (Section 7) because it is constructed before approval commits the Mission: the Mission id and lifecycle do not yet exist, and the disclosure must commit only to the proposed Intent and Authority Set it actually renders. The Consent Evidence object, recorded at or after the decision, carries the resolved mission container with id, origin, and the same anchors.¶

shaping_evidence_hash:

OPTIONAL. A string. A commitment to Shaping Evidence when shaping was used ([I-D.draft-mcguinness-oauth-mission-shaping]).¶

predecessor:

OPTIONAL. A string. The predecessor Mission identifier when this disclosure is for an expansion approval ([I-D.draft-mcguinness-oauth-mission-expansion]).¶

display_context:

REQUIRED. An object containing presentation context, including at least channel (for example, web, device, api, or admin_console) and rendered_at.¶

approver_actions:

OPTIONAL. An array describing explicit approver interactions required by policy, such as checking a high-risk notice or confirming an expansion delta.¶

A Consent Disclosure object MUST NOT omit material authority. If the Authority Set includes delegation, external commitments, irreversible actions, privileged administration, cross-domain authority, or consumption bounds, the disclosure MUST include a material notice or a rendered authority summary entry covering that fact.¶

5. consent_rendering_hash

consent_rendering_hash is the integrity-anchor encoded form of the SHA-256 [RFC6234] of the JCS [RFC8785] canonical bytes of this envelope:¶

{
  "typ": "mission-consent-disclosure",
  "iss": <mission.origin>,
  "value": <Consent Disclosure object>
}

The value uses the same algorithm-agile integrity-anchor encoding the issuance profile [I-D.draft-mcguinness-oauth-mission] defines for intent_hash and authority_hash: a collision-resistant hash-name prefix and the base64url digest, for example sha-256:.... A consumer MUST treat the prefix as identifying the hash function and MUST NOT assume SHA-256; this lets the commitment migrate to a stronger function without ambiguity.¶

The hash commits the disclosure object, not pixels or browser state. A deployment MAY additionally retain screenshots or UI telemetry, but the interoperable commitment is the structured disclosure object.¶

So that the committed object can be related to what a human would see, the rendering SHOULD be a deterministic function of the disclosure object and its template_id, template_version, and locale: the same inputs MUST produce the same rendered form, and the named template MUST be retrievable or reconstructable by an authorized auditor for the retention period (Section 9). An auditor can then re-render the recorded disclosure into the form the Approver should have been shown. This does not prove what was displayed, but it reduces the gap from "the rendering layer showed something unverifiable" to "did the rendering layer execute a published deterministic template," which the higher rungs of Section 6 then address.¶

The Mission Issuer SHOULD record consent_rendering_hash on the Mission record. When the Mission claim is extended to carry the value, it MUST carry the same prefixed integrity-anchor form, and consumers MUST treat it as audit data only; it MUST NOT grant or widen authority.¶

The Consent Disclosure object MUST be constructed after Authority Set derivation and before approval. If the Authority Set changes after the disclosure is constructed, the Mission Issuer MUST discard the disclosure and construct a new one; it MUST NOT reuse the prior consent_rendering_hash.¶

6. Rendering Assurance

The commitment of Section 5 records what disclosure the Authorization Server says it rendered; it cannot by itself prove what a human perceived. This is the what-you-see-is-what-you-sign problem. This profile does not close it with a server-side commitment, which is impossible, but defines a ladder a deployment climbs as far as its threat model requires. Each rung shrinks the trusted rendering base; to claim a rung a deployment satisfies it and records the corresponding evidence. The rungs are cumulative: claiming a rung requires satisfying the rungs below it, so a Rung 3 confirmation is over a disclosure that is also deterministically renderable (Rung 1) and an auditor can re-render exactly what the confirmation signed.¶

Rung 0, Recorded disclosure:

The baseline of Section 5: the structured disclosure is committed and bound to the Mission anchors. Proves the AS recorded this disclosure for this authority; proves nothing about what was shown.¶

Rung 1, Deterministic rendering:

The rendering is a deterministic function of the disclosure object and its committed template (Section 5), so an auditor can re-render the intended form. The open question narrows to whether the rendering layer faithfully executed a published template.¶

Rung 2, Attested rendering:

The Consent Evidence carries a rendering_attestation (Section 7): evidence that an attested, identified rendering component (a first-party AS-hosted consent surface, or a renderer attested by the platform or a trusted execution environment) produced the rendering. The trusted base shrinks from any rendering layer to an attested one.¶

Rung 3, Approver confirmation:

The Consent Evidence carries a rendering_confirmation (Section 7): a signature produced by the Approver's authenticator over the consent_rendering_hash at approval, binding the approval credential itself to the exact committed disclosure. The claim that the Approver approved this disclosure then rests on the Approver's authenticator, not on the Authorization Server. This is the what-you-see-is-what-you-sign rung, as in authenticator transaction-confirmation schemes. A deployment SHOULD reach this rung for a Mission whose Authority Set carries a high-risk material-notice class (Section 4.1): irreversible actions, external commitments, privileged administration, or cross-domain disclosure.¶

Rung 4, Out-of-band confirmation:

For the most material actions, confirmation is obtained at execution time on a channel the rendering layer does not control, as the action-bound approval of the runtime layer ([I-D.draft-mcguinness-oauth-mission-runtime]); a rendering layer would then have to compromise two independent paths. That is a runtime-layer mechanism recorded as its own evidence; this profile records the approval-time rungs above.¶

No rung proves the Approver perceived or understood the disclosure; a compromised authenticator or trusted execution environment, or an Approver who confirms without reading, remains outside reach, as for any electronic-signature scheme. What the ladder provides is a verifiable, bounded reduction of the rendering trust base: at Rung 3 the claim that the Approver approved a specific disclosure is verifiable up to trust in the Approver's authenticator, rather than in an arbitrary rendering layer.¶

7. Consent Evidence Object

A Consent Evidence object has these members:¶

evidence_id:

REQUIRED. A string. Unique evidence identifier.¶

mission:

REQUIRED. An object binding the evidence to what was approved. Its shape depends on decision, because a Mission exists only after an approval ([I-D.draft-mcguinness-oauth-mission]): - When decision is approved, it contains id, origin, intent_hash, authority_hash, and, when this profile records it on the Mission, consent_rendering_hash. - When decision is declined, no Mission was created (Section 8.1), so there is no id. It instead contains origin and the intent_hash and authority_hash the disclosure corresponded to, matching the disclosure object's source_hashes (Section 4). It MUST NOT contain id.¶

This descriptor follows the evidence-descriptor convention of the issuance profile ([I-D.draft-mcguinness-oauth-mission]): it is the mission claim shape extended with the collision-resistantly named audit members intent_hash and consent_rendering_hash, and it is not authority-bearing on its own.¶

approver:

REQUIRED. An object identifying the authenticated Approver.¶

subject:

REQUIRED when different from the Approver. An object identifying the Subject.¶

client:

REQUIRED when known. An object identifying the client or agent requesting the Mission.¶

authentication_context:

REQUIRED. An object recording the acr, amr, and authentication time used for the approval event when available.¶

disclosure:

REQUIRED. The Consent Disclosure object, or an object containing a durable reference and the consent_rendering_hash.¶

rendering_attestation:

OPTIONAL. An object. Evidence that an attested, identified rendering component produced the rendering shown to the Approver (Rung 2, Section 6). Its members are deployment-defined and identify the attested component and its attestation; this profile fixes the role, not the attestation format.¶

rendering_confirmation:

OPTIONAL. An object. A confirmation produced by the Approver's authenticator at approval (Rung 3, Section 6). To bind the trust to the Approver rather than the Authorization Server, it MUST sign the consent_rendering_hash together with a per-approval value (the evidence_id, or a nonce echoed in authentication_context), so a captured confirmation cannot be replayed into another record, and it MUST carry or reference an authenticator credential that the verifier can confirm is bound to the recorded approver. This profile fixes what is signed and bound, not the authenticator protocol. A deployment SHOULD include it for a high-risk material-notice class (Section 4.1). When present, a verifier MUST check it as part of Section 7.1 and MUST treat a confirmation that does not verify, or whose authenticator is not bound to the recorded approver, as an integrity failure.¶

approved_at:

REQUIRED when decision is approved. An RFC 3339 [RFC3339] timestamp.¶

declined_at:

REQUIRED when decision is declined. An RFC 3339 timestamp.¶

decision:

REQUIRED. One of approved or declined.¶

decline_reason:

OPTIONAL. A string. Present when decision is declined and the deployment records a reason.¶

policy_version:

REQUIRED when known. The approval policy version in effect at the approval event.¶

sequence:

REQUIRED. An integer. A per-Mission-Issuer consent evidence sequence value or another deployment-defined monotonic indicator sufficient to reconstruct evidence order.¶

evidence_envelope:

REQUIRED when retained as a portable record. An object carrying format and value. This document defines jws-compact, a JWS Compact Serialization [RFC7515] over the JCS canonical bytes of the Consent Evidence object with evidence_envelope removed.¶

Example:¶

{
  "evidence_id": "cns_7rP2kL9mQ4",
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "origin": "https://as.example.com",
    "intent_hash": "sha-256:wQ7p4LHnX9Md0LqJ6sZJ8b8mZ3rN2xT5pV4lE6sQqYY",
    "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
    "consent_rendering_hash":
      "sha-256:CnS3nT9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4xVz"
  },
  "approver": {
    "iss": "https://idp.example.com",
    "sub": "alice"
  },
  "authentication_context": {
    "acr": "urn:example:acr:phishing-resistant",
    "amr": ["pwd", "hwk"],
    "auth_time": "2026-06-30T17:54:00Z"
  },
  "approved_at": "2026-06-30T17:55:00Z",
  "decision": "approved",
  "policy_version": "approval-policy:v12",
  "sequence": 88127,
  "disclosure": {
    "disclosure_id": "disc_4pQ9z",
    "consent_rendering_hash":
      "sha-256:CnS3nT9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4xVz"
  },
  "evidence_envelope": {
    "format": "jws-compact",
    "value": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImNvbnNlbnQt..."
  }
}

8. Binding to Mission Approval

At an approval event, a Consent-Evidence-capable Mission Issuer MUST:¶

1. derive the Authority Set and compute intent_hash and authority_hash under [I-D.draft-mcguinness-oauth-mission];¶

2. construct the Consent Disclosure object from that exact Authority Set and Mission Intent;¶

3. compute consent_rendering_hash;¶

4. render the disclosure to the Approver;¶

5. record Consent Evidence for approved or declined; and¶

6. when approved, bind the Mission record to the consent_rendering_hash.¶

For expansion approvals, the disclosure MUST identify the predecessor Mission and distinguish retained authority from newly requested authority.¶

9. Audit Reconstruction

A deployment claiming this profile MUST retain enough information for an authorized auditor to reconstruct:¶

• the Mission Intent and Authority Set approved;¶

• the Consent Disclosure object;¶

• the template, template version, and locale;¶

• the material notices presented;¶

• the Approver, Subject, and approval authentication context; and¶

• the integrity path from Consent Evidence to the Mission record.¶

Retention MUST last at least as long as the Mission's audit horizon.¶

10. Conformance

A conforming Consent-Evidence-capable Mission Issuer MUST:¶

• construct a Consent Disclosure object for each approval event;¶

• compute consent_rendering_hash;¶

• record Consent Evidence for approval and decline decisions;¶

• bind approved Mission records to consent_rendering_hash;¶

• include material notices for high-risk authority; and¶

• retain evidence for audit reconstruction.¶

A conforming verifier of Consent Evidence MUST implement the checks in Section 7.1 and MUST treat failure to retrieve a referenced disclosure during the retention window as an audit failure.¶

11. Security Considerations

12. Privacy Considerations

Consent Evidence can contain sensitive task descriptions, business context, approver identity, subject identity, and high-risk authority details. Deployments SHOULD protect it at least as strongly as Mission records and runtime evidence. Where possible, portable records SHOULD carry hashes or references rather than full rendered text, while still allowing authorized audit reconstruction.¶

13. IANA Considerations

This document makes no IANA request.¶

Future versions may request registration for application/mission-consent-evidence+json if portable exchange of Consent Evidence becomes an interoperability requirement. Until such a registration exists, deployments using this media type do so by local agreement.¶

14. References

Acknowledgments

This document is part of the Mission-Bound Authorization for OAuth 2.0 set and binds the approval surface to the Mission authority record.¶

Author's Address