Network Working Group K. McGuinness Internet-Draft Independent Intended status: Standards Track 23 June 2026 Expires: 25 December 2026 Mission Consent Evidence for OAuth 2.0 draft-mcguinness-oauth-mission-consent-evidence-latest Abstract Mission-Bound Authorization for OAuth 2.0 commits the approved Mission Intent and Authority Set, but does not commit the exact consent disclosure shown to the Approver. This document defines an OPTIONAL Consent Evidence profile. It specifies a structured consent disclosure object, a consent_rendering_hash integrity anchor, and a signed Consent Evidence object that records what was shown, who approved it, which Mission authority it corresponded to, and which notices or material risks were presented. The profile lets an auditor reconstruct the approval surface without making the disclosure itself an authority grant. 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/draft-mcguinness-oauth-mission/draft- mcguinness-oauth-mission-consent-evidence.html. Status information for this document may be found at https://datatracker.ietf.org/doc/ draft-mcguinness-oauth-mission-consent-evidence/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/draft-mcguinness-oauth-mission. 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 25 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 2. Scope 2.1. Evidence Model 3. Conventions and Terminology 4. Consent Disclosure Object 4.1. Material Notice Requirements 5. consent_rendering_hash 6. Consent Evidence Object 6.1. Integrity and Verification 7. Binding to Mission Approval 7.1. Declined Approval Events 7.2. Expansion and Delta Disclosure 8. Audit Reconstruction 8.1. Minimization and Redaction 9. Conformance 10. Security Considerations 10.1. Rendering Confusion 10.2. Template Downgrade 10.3. Evidence Does Not Grant Authority 10.4. Decline Suppression 10.5. Incomplete Material Notices 11. Privacy Considerations 12. IANA Considerations 13. References 13.1. Normative References 13.2. Informative References Acknowledgments Author's Address 1. Introduction The issuance profile [I-D.draft-mcguinness-oauth-mission] 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 closes 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. 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 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 6); * binding rules for initial Mission approval and expansion approval (Section 7); * retention and audit reconstruction requirements (Section 8); and * conformance for a Consent-Evidence-capable Mission Issuer (Section 9). 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. 2.1. Evidence Model This profile separates three artifacts: 1. the Mission Intent and Authority Set, which define what is being approved under [I-D.draft-mcguinness-oauth-mission]; 2. the Consent Disclosure object, which defines what the Approver was shown in structured form; and 3. the Consent Evidence object, which records the approval or decline event and integrity-protects the disclosure commitment. Only the approved Mission grants authority. The disclosure and evidence objects prove the approval surface and are audit artifacts. 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. 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. 4.1. Material Notice Requirements A material notice is required for each of these conditions when present in the proposed Authority Set or Mission context: * delegation to another actor or child Mission; * authority that crosses an organizational or issuer boundary; * irreversible action; * external commitment; * privileged administration; * broad, bulk, export-like, or privacy-sensitive read; * consumption bounds that can be exhausted by the agent; * Mission expansion that widens authority; * authority that can affect a party other than the Subject or Approver; and * runtime enforcement gaps disclosed by the deployment. Each notice MUST identify the Authority Set entry or entries it describes. A generic warning that "this may be risky" is not sufficient for this profile. 5. consent_rendering_hash consent_rendering_hash is the integrity-anchor encoded form of the SHA-256 of the JCS canonical bytes of this envelope: { "typ": "mission-consent-disclosure", "iss": , "value": } 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. The Mission Issuer SHOULD record consent_rendering_hash on the Mission record. When the Mission claim is extended to carry the value, 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. Consent Evidence Object A Consent Evidence object has these members: evidence_id: REQUIRED. A string. Unique evidence identifier. mission: REQUIRED. An object containing id, origin, intent_hash, authority_hash, and, when this profile records it on the Mission, consent_rendering_hash. 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. 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_8RfX2Lqv9TqMv4z7sA2bN1k0YpEd", "origin": "https://as.example.com", "intent_hash": "sha-256:wQ7p4LHnX9Md0LqJ6sZJ8b8mZ3rN2xT5pV4lE6s", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE", "consent_rendering_hash": "sha-256:CnS3nT9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4" }, "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:CnS3nT9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4" }, "evidence_envelope": { "format": "jws-compact", "value": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImNvbnNlbnQt..." } } 6.1. Integrity and Verification When evidence_envelope.format is jws-compact, the protected header MUST identify a signing key controlled by the Mission Issuer or an evidence service authorized by the Mission Issuer. A verifier: 1. removes evidence_envelope; 2. canonicalizes the remaining Consent Evidence object with JCS; 3. verifies the JWS payload against those bytes; 4. verifies the signing key against the Mission Issuer's published key material or configured trust anchors; 5. recomputes consent_rendering_hash over the Consent Disclosure object or verifies the referenced disclosure against that hash; and 6. verifies that the Mission anchors in mission match the Mission record being audited. Evidence whose format is unsupported MUST be rejected rather than accepted without verification. 7. 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. 7.1. Declined Approval Events Declined approval events are security-relevant. A deployment claiming this profile MUST record Consent Evidence when an Approver declines a Mission or expansion request. The evidence MAY omit sensitive free-form decline text, but it MUST record the disclosure commitment, decision, Approver, time, and policy version when known. Declined evidence MUST NOT create a Mission, Mission claim, token, or authority. It exists to prevent silent retry, coercion, and rendering confusion from being invisible to audit. 7.2. Expansion and Delta Disclosure When the approval event is for Mission Expansion, the Consent Disclosure object MUST distinguish: * authority retained from the predecessor; * authority newly added; * authority removed or narrowed; * changes to Mission expiry; * changes to delegation or child-Mission rights; and * the predecessor Mission identifier. An expansion disclosure that renders only the final Authority Set without the delta is not conforming to this profile, because it fails to show what is being widened. 8. 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. 8.1. Minimization and Redaction The portable Consent Evidence object MAY contain a durable reference to the full Consent Disclosure object rather than the full object itself, provided the reference is access-controlled and the evidence includes consent_rendering_hash. A verifier with authorization MUST be able to retrieve or reconstruct the disclosure for the retention period. Free-form task text and approver comments SHOULD be redacted or stored by reference when not required for ordinary audit. 9. 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 6.1 and MUST treat failure to retrieve a referenced disclosure during the retention window as an audit failure. 10. Security Considerations 10.1. Rendering Confusion The primary threat is rendering confusion: the Approver sees one thing while the Mission records another. This profile mitigates that by committing a structured disclosure object to the same Mission anchors used for authority. 10.2. Template Downgrade An attacker could use an outdated or less explicit template. The Consent Disclosure object includes template_id and template_version; deployments SHOULD reject templates not approved for the action classes being authorized. 10.3. Evidence Does Not Grant Authority Consent Evidence proves what was shown and decided. It MUST NOT be accepted as a token, grant, or substitute for the Mission's authority_hash. 10.4. Decline Suppression An attacker could repeatedly reshape and resubmit a declined Mission to obtain approval through fatigue. Recording declined events lets deployments detect repeated attempts against the same task, requester, or Authority Set. 10.5. Incomplete Material Notices If material notices omit high-risk authority, the Approver's consent may not be meaningful. Deployments SHOULD test disclosure templates against Authority Set fixtures and reject templates that cannot render all material notice classes. 11. 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. 12. 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. 13. References 13.1. Normative References [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness- oauth-mission, 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, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . 13.2. Informative References [I-D.draft-mcguinness-oauth-mission-expansion] McGuinness, K., "Mission Expansion for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness-oauth-mission- expansion, 2026, . [I-D.draft-mcguinness-oauth-mission-shaping] McGuinness, K., "Mission Intent Shaping for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness-oauth- mission-shaping, 2026, . 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 Karl McGuinness Independent Email: public@karlmcguinness.com