Web Authorization Protocol D. Liu Internet-Draft H. Zhu Intended status: Standards Track Alibaba Group Expires: 12 December 2026 S. Krishnan Cisco A. Parecki Okta June 2026 Authorization Evidence and Audit Trail for OAuth 2.0 Access Tokens draft-liu-oauth-authorization-evidence-00 Abstract This specification defines JWT claims for including authorization evidence and audit trail information in OAuth 2.0 access tokens. These claims enable cryptographic proof of user consent, supporting accountability, compliance, and dispute resolution in scenarios where autonomous agents act on behalf of users. 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 3 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 Liu, et al. Expires 12 December 2026 [Page 1] Internet-Draft OAuth Authorization Evidence June 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The evidence Claim . . . . . . . . . . . . . . . . . . . . . 4 3.1. Claim Definition . . . . . . . . . . . . . . . . . . . . 5 3.2. Structure . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Field Definitions . . . . . . . . . . . . . . . . . . . . 5 3.3.1. user_confirmation Object . . . . . . . . . . . . . . 6 3.4. AS Signature . . . . . . . . . . . . . . . . . . . . . . 6 4. The audit_trail Claim . . . . . . . . . . . . . . . . . . . . 8 4.1. Claim Definition . . . . . . . . . . . . . . . . . . . . 8 4.2. Structure . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Field Definitions . . . . . . . . . . . . . . . . . . . . 8 4.4. Semantic Expansion Levels . . . . . . . . . . . . . . . . 9 4.5. Minimum Content Guidance . . . . . . . . . . . . . . . . 10 5. Audit Trail Purposes . . . . . . . . . . . . . . . . . . . . 10 6. Authorization Server Processing . . . . . . . . . . . . . . . 10 6.1. Evidence Collection from User Interaction . . . . . . . . 11 6.1.1. General Consent-to-Evidence Pattern . . . . . . . . . 11 6.1.2. Consent UI to Evidence Field Mapping . . . . . . . . 12 6.1.3. Example: JWT Grant Interaction Response Flow . . . . 13 6.1.4. Applicability to Other Flows . . . . . . . . . . . . 14 6.2. Evidence Generation . . . . . . . . . . . . . . . . . . . 15 6.3. Storage Requirements . . . . . . . . . . . . . . . . . . 15 6.4. Evidence in Token Exchange . . . . . . . . . . . . . . . 16 6.5. Evidence in Token Refresh . . . . . . . . . . . . . . . . 16 7. Resource Server Processing . . . . . . . . . . . . . . . . . 17 7.1. Evidence Verification . . . . . . . . . . . . . . . . . . 17 7.2. Audit Logging . . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8.1. Signature Verification . . . . . . . . . . . . . . . . . 18 8.2. Evidence Tampering and Trust in the AS . . . . . . . . . 18 8.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 18 8.4. Token Size Considerations . . . . . . . . . . . . . . . . 18 8.5. Token-Evidence Binding . . . . . . . . . . . . . . . . . 19 8.6. Evidence Freshness . . . . . . . . . . . . . . . . . . . 19 8.7. Cross-Domain Evidence Verification . . . . . . . . . . . 20 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 9.1. Displayed Content . . . . . . . . . . . . . . . . . . . . 20 9.2. Evidence Retention . . . . . . . . . . . . . . . . . . . 21 9.3. Right to Erasure and Audit Retention . . . . . . . . . . 21 Liu, et al. Expires 12 December 2026 [Page 2] Internet-Draft OAuth Authorization Evidence June 2026 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10.1. JWT Claims Registration . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. Complete Example . . . . . . . . . . . . . . . . . . 24 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction In traditional OAuth 2.0 [RFC6749] flows, the Authorization Server records user consent internally, but this information is not typically conveyed to Resource Servers or included in access tokens. For many use cases, this is sufficient. However, emerging scenarios, particularly those involving AI agents acting autonomously on behalf of users, require stronger guarantees about user intent and consent. This specification addresses the need for: * Verifiable consent: Cryptographic proof that a user explicitly authorized a specific operation; * Audit trails: Traceable records linking user intent to system actions; * Dispute resolution: Evidence that can be examined if questions arise about what was authorized; * Regulatory compliance: Documentation required by regulations in finance, healthcare, and other domains. This specification defines two JWT claims: evidence for user confirmation records, and audit_trail for semantic traceability metadata. Unless otherwise noted, all data types and serialization rules follow the JSON data interchange format as defined in [RFC8259]. 1.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. Liu, et al. Expires 12 December 2026 [Page 3] Internet-Draft OAuth Authorization Evidence June 2026 1.2. Applicability This specification defines general-purpose JWT claims that MAY be used with various OAuth 2.0 authorization flows, including but not limited to: * JWT Authorization Grant with Interaction Response [I-D.parecki-oauth-jwt-grant-interaction-response]; * Authorization Code Grant (with or without PAR [RFC9126]); * Client Credentials Grant; * Token Exchange [RFC8693]; * Any other OAuth 2.0 grant type that involves user authorization. Different authorization flows may have different security considerations when using this specification. Implementations SHOULD carefully evaluate the security implications based on their specific deployment scenario. 2. Terminology User Confirmation: An explicit action by the user (e.g., clicking "Allow") to approve an authorization request. Displayed Content: The human-readable description of the operation shown to the user during the consent flow. Evidence: A cryptographically signed record of user confirmation, including what was displayed and how the user responded. Audit Trail: Metadata that enables tracing from user intent through system interpretation to final authorized action. Semantic Expansion: The process of translating user intent (e.g., natural language) into concrete system operations. 3. The evidence Claim The evidence claim contains a record of the user's confirmation action during the authorization process. It is included in JWT access tokens [RFC7519] to provide verifiable proof of user consent. Liu, et al. Expires 12 December 2026 [Page 4] Internet-Draft OAuth Authorization Evidence June 2026 3.1. Claim Definition Claim Name: evidence Claim Type: Object Usage: Access tokens 3.2. Structure { "evidence": { "id": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6", "user_confirmation": { "displayed_content": "Add items under $50 to cart", "user_action": "confirmed_via_button_click", "timestamp": 1731320595 }, "as_signature": "eyJhbGciOiJFUzI1NiJ9..MEUCIQDx..." } } Figure 1 3.3. Field Definitions +===================+======+===========+==========================+ | Field |Type |Requirement| Description | +===================+======+===========+==========================+ | id |string|REQUIRED | Unique identifier for | | | | | this evidence record. | | | | | The value MUST use a URI | | | | | or URN format with at | | | | | least 128 bits of | | | | | collision resistance. | | | | | UUID URNs (e.g., | | | | | "urn:uuid:f81d4fae-7dec- | | | | | 11d0-a765-00a0c91e6bf6") | | | | | are RECOMMENDED. | +-------------------+------+-----------+--------------------------+ | user_confirmation |object|REQUIRED | Details of the user's | | | | | confirmation action. | +-------------------+------+-----------+--------------------------+ | as_signature |string|REQUIRED | AS signature over the | | | | | confirmation record. | +-------------------+------+-----------+--------------------------+ Table 1: evidence Claim Fields Liu, et al. Expires 12 December 2026 [Page 5] Internet-Draft OAuth Authorization Evidence June 2026 3.3.1. user_confirmation Object +=================+===========+===========+=========================+ |Field |Type |Requirement| Description | +=================+===========+===========+=========================+ |displayed_content|string |REQUIRED | The text shown to user | | | | | for confirmation. | +-----------------+-----------+-----------+-------------------------+ |user_action |string |REQUIRED | How the user confirmed | | | | | the operation. The | | | | | value is a free-form | | | | | string, but | | | | | implementations SHOULD | | | | | use values from the | | | | | following set for | | | | | interoperability: | | | | | button_click, | | | | | biometric_confirmation, | | | | | pin_entry, | | | | | voice_confirmation, | | | | | hardware_key, | | | | | implicit_consent. | | | | | Custom values MAY be | | | | | used for deployment- | | | | | specific confirmation | | | | | mechanisms. | +-----------------+-----------+-----------+-------------------------+ |timestamp |NumericDate|REQUIRED | When the confirmation | | | | | occurred. | +-----------------+-----------+-----------+-------------------------+ Table 2: user_confirmation Fields 3.4. AS Signature The as_signature field contains a cryptographic signature from the Authorization Server over the evidence record. This signature: * Proves the AS witnessed the user's consent; * Ensures the evidence has not been tampered with; * Provides strong evidence of user consent for dispute resolution (subject to trust in the AS, as discussed in Section 8). The signature MUST be computed over the following fields of the evidence object: Liu, et al. Expires 12 December 2026 [Page 6] Internet-Draft OAuth Authorization Evidence June 2026 * id * user_confirmation (entire object) The as_signature field itself MUST be excluded from the signature computation. The signature format MUST be a detached JWS [RFC7515] in Compact Serialization using the AS's signing key. In detached Compact Serialization (see RFC 7515 Appendix F), the payload portion is omitted, resulting in the format "header..signature". The signature input is constructed using the following deterministic algorithm: 1. Create a new JSON object containing only the id and user_confirmation fields copied from the evidence object. No other fields from the evidence object are included. 2. Apply the JSON Canonicalization Scheme (JCS) as defined in [RFC8785] to the JSON object from the previous step, producing a deterministic byte string. 3. Compute a detached JWS (Compact Serialization) over the JCS output from Step 2 using the AS's private signing key. The resulting value (header..signature) is stored in the as_signature field of the evidence object. To verify an as_signature, the verifier reconstructs the JCS input by performing Steps 1 and 2 above on the received evidence object (excluding the as_signature field), then verifies the detached JWS using the AS's public key. Any extension fields present in the evidence object beyond id, user_confirmation, and as_signature MUST NOT be included in the JCS input and therefore are not covered by the signature. Note: In examples throughout this document, the as_signature value is shown in abbreviated form for readability. Actual values MUST use the detached JWS Compact Serialization format described above. The key used to sign the evidence record MAY be the same key used to sign the access token, or it MAY be a separate dedicated key. When a separate key is used, implementations MUST ensure that the evidence signing key is associated with the AS through a verifiable mechanism (e.g., published in the AS's JWKS endpoint as defined in [RFC7517]). Using a dedicated evidence signing key enables independent key rotation for evidence records without affecting token validation, which is RECOMMENDED for deployments where evidence records have longer retention periods than access tokens. Liu, et al. Expires 12 December 2026 [Page 7] Internet-Draft OAuth Authorization Evidence June 2026 4. The audit_trail Claim The audit_trail claim provides metadata for semantic traceability, enabling analysis of how user intent was interpreted and translated into authorized operations. 4.1. Claim Definition Claim Name: audit_trail Claim Type: Object Usage: Access tokens 4.2. Structure { "audit_trail": { "evidence_ref": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6", "semantic_expansion_level": "medium", "proposal_ref": "urn:uuid:proposal-xyz" } } Figure 2 4.3. Field Definitions +==========================+========+=============+=================+ | Field | Type | Requirement | Description | +==========================+========+=============+=================+ | evidence_ref | string | OPTIONAL | Reference to | | | | | the evidence | | | | | record by ID. | +--------------------------+--------+-------------+-----------------+ | semantic_expansion_level | string | OPTIONAL | Degree of | | | | | interpretation | | | | | applied (none, | | | | | low, medium, | | | | | high). | +--------------------------+--------+-------------+-----------------+ | proposal_ref | URI | OPTIONAL | Reference to | | | | | the original | | | | | authorization | | | | | proposal, the | | | | | agent's | | | | | initial | | | | | request | Liu, et al. Expires 12 December 2026 [Page 8] Internet-Draft OAuth Authorization Evidence June 2026 | | | | describing the | | | | | intended | | | | | operation | | | | | before the AS | | | | | applied policy | | | | | evaluation, | | | | | scope | | | | | reduction, or | | | | | user consent | | | | | modifications. | | | | | The value is | | | | | an opaque URI | | | | | assigned by | | | | | the AS for | | | | | internal | | | | | correlation; | | | | | no protocol | | | | | for retrieving | | | | | the proposal | | | | | content via | | | | | this URI is | | | | | defined by | | | | | this | | | | | specification. | | | | | This enables | | | | | post-hoc | | | | | comparison | | | | | between what | | | | | the agent | | | | | originally | | | | | requested and | | | | | what was | | | | | ultimately | | | | | authorized. | +--------------------------+--------+-------------+-----------------+ Table 3: audit_trail Claim Fields 4.4. Semantic Expansion Levels The semantic_expansion_level field indicates how much the system interpreted or expanded the user's original intent. The following four values form a closed set; implementations MUST NOT use values outside this set: none: No interpretation; user specified exact parameters. Example: User explicitly sets "transfer $100 to account X". Liu, et al. Expires 12 December 2026 [Page 9] Internet-Draft OAuth Authorization Evidence June 2026 low: Minor defaults applied. Example: User says "add to cart" and the system defaults quantity to 1 and selects the user's saved shipping address. medium: Significant interpretation of qualitative terms. Example: User says "buy cheap headphones" and the system maps "cheap" to a price ceiling of $50 and selects a specific product category. high: Substantial expansion from a high-level goal into a multi-step plan. Example: User says "plan my trip to Tokyo" and the agent derives flight search, hotel booking, and itinerary creation as separate authorized operations. 4.5. Minimum Content Guidance When the audit_trail claim is included, the evidence_ref field SHOULD be present to link the audit record to its corresponding evidence. Including at least evidence_ref and semantic_expansion_level is RECOMMENDED for meaningful audit capability. 5. Audit Trail Purposes The evidence and audit trail claims serve several important purposes: +================+=================================================+ | Purpose | Description | +================+=================================================+ | Intent | Records what the user intended, preventing | | Provenance | disputes about authorization scope. | +----------------+-------------------------------------------------+ | Action | Documents how the system translated intent into | | Interpretation | operations, showing the reasoning process. | +----------------+-------------------------------------------------+ | Semantic | Reveals any expansions or defaults applied, | | Transparency | enabling users to understand what was | | | authorized. | +----------------+-------------------------------------------------+ | User | Provides timestamped proof that the user | | Confirmation | reviewed and approved the operation. | +----------------+-------------------------------------------------+ | Accountability | Enables post-hoc analysis to determine | | Support | responsibility for erroneous transactions. | +----------------+-------------------------------------------------+ Table 4: Purposes of Authorization Evidence 6. Authorization Server Processing Liu, et al. Expires 12 December 2026 [Page 10] Internet-Draft OAuth Authorization Evidence June 2026 6.1. Evidence Collection from User Interaction The evidence claim records the outcome of a user consent interaction. Before the AS can generate a signed evidence record, it must first present a consent interface to the user and capture the user's response. This section describes the general consent-to-evidence pattern and provides a concrete example using the JWT Grant Interaction Response flow. 6.1.1. General Consent-to-Evidence Pattern Regardless of the specific OAuth grant type, evidence collection follows a common pattern: 1. The AS receives an authorization request from a client (which may be acting on behalf of an AI agent). 2. The AS determines that user consent is required and presents a consent interface to the user. The consent interface displays a human-readable description of the requested operation (the displayed_content). 3. The user reviews the displayed content and performs a confirmation action (e.g., clicking an "Allow" button, providing biometric input, entering a PIN). 4. The AS captures the interaction details (what was displayed, what action the user took, when, and in what session context) and constructs the evidence object as defined in Section 3. 5. The AS signs the evidence record and includes it in the issued access token. The following diagram illustrates this pattern: Liu, et al. Expires 12 December 2026 [Page 11] Internet-Draft OAuth Authorization Evidence June 2026 Client/Agent Authorization Server User | | | |-- authorization req --->| | | | | | |--- consent UI ---------->| | | (displayed_content) | | | | | |<-- user action ----------| | | (button_click, etc.) | | | | | | [capture evidence] | | | [sign with as_signature]| | | | |<-- access token --------| | | (with evidence) | | | | | Figure 3 6.1.2. Consent UI to Evidence Field Mapping Each field in the evidence claim corresponds to a specific event during the consent interaction: +==============+===================+========================+ | Consent UI | Evidence Field | Description | | Event | | | +==============+===================+========================+ | AS renders | displayed_content | The text shown to the | | consent page | | user describing the | | | | requested operation | +--------------+-------------------+------------------------+ | User | user_action | How the user responded | | confirms or | | (button click, | | denies | | biometric, PIN, etc.) | +--------------+-------------------+------------------------+ | Confirmation | timestamp | Server-side time when | | timestamp | | the user's action was | | | | received | +--------------+-------------------+------------------------+ Table 5: Consent UI Event to Evidence Field Mapping Liu, et al. Expires 12 December 2026 [Page 12] Internet-Draft OAuth Authorization Evidence June 2026 6.1.3. Example: JWT Grant Interaction Response Flow The JWT Grant Interaction Response ([I-D.parecki-oauth-jwt-grant-interaction-response]) defines a mechanism for AI agents to obtain user consent from an external Authorization Server. The following sequence shows how evidence is collected during this flow: 1. An AI agent sends a token request to the AS using a JWT authorization grant ([RFC7523]), including the requested scope and authorization_details. 2. The AS validates the agent's identity and determines that user interaction is required. It responds with an interaction_required error containing an interaction_uri (a URL hosted by the AS for the consent interface) and a polling interval. 3. The agent opens the interaction_uri in the user's browser. The AS presents a consent page showing the interpreted operation (e.g., "Add items under $50 to cart on your behalf"). 4. The user reviews the displayed content and clicks "Allow". The AS captures: * displayed_content: the operation description shown on the consent page; * user_action: button_click; * timestamp: the server time of the click. 5. The AS constructs the evidence object, computes the as_signature per Section 3, and stores the evidence record. 6. The agent polls the token endpoint. Upon detecting that the user has completed interaction, the AS issues an access token containing the signed evidence claim. Liu, et al. Expires 12 December 2026 [Page 13] Internet-Draft OAuth Authorization Evidence June 2026 AI Agent External AS User | | | |-- token request ->| | | | | |<- interaction_ | | | required | | | (interaction_ | | | uri, interval) | | | | | |-- open interaction_uri in browser ------------>| | | | | |--- consent UI ------------>| | | "Add items under $50 | | | to cart on your behalf"| | | | | |<-- user clicks [Allow] ----| | | | | | [capture evidence fields] | | | [compute as_signature] | | | | |-- poll token --->| | | endpoint | | | | | |<- access token ---| | | (with evidence) | | | | | Figure 4 6.1.4. Applicability to Other Flows The consent-to-evidence pattern described above applies to any OAuth flow that involves user interaction. For example: * *Authorization Code Grant*: The AS presents a consent screen during the /authorize redirect. Evidence is collected when the user approves or denies the request. * *CIBA (Client-Initiated Backchannel Authentication)*: The AS delivers a consent request to the user's authentication device (e.g., push notification). Evidence captures the user's out-of- band confirmation action. * *Consent-Only Flow*: When the user already holds a valid session and the AS determines that only operation-specific consent is needed (not re-authentication), the AS presents a targeted consent prompt. Evidence records the scoped approval. Liu, et al. Expires 12 December 2026 [Page 14] Internet-Draft OAuth Authorization Evidence June 2026 Flows that do not involve user interaction (e.g., Client Credentials Grant without user context) cannot produce evidence claims, since there is no user confirmation to record. Such flows MAY still use the audit_trail claim (Section 4) for semantic traceability without user confirmation evidence. 6.2. Evidence Generation When issuing an access token with evidence, the AS MUST: 1. Record the exact content displayed to the user during consent; 2. Capture the user's confirmation action and timestamp; 3. Generate a unique evidence identifier; 4. Sign the evidence fields (id and user_confirmation) with the AS's private key using JCS canonicalization; 5. Include the evidence claim in the access token. 6.3. Storage Requirements The AS SHOULD retain evidence records for a configurable period to support: * Dispute resolution; * Regulatory compliance; * Audit requests; * Token introspection with evidence details. The retention period SHOULD be at least as long as the longest-lived token that references the evidence record, plus a configurable grace period for post-expiration disputes. For regulated industries (e.g., financial services under PCI-DSS, healthcare under HIPAA), the retention period MUST comply with the applicable regulatory minimums, which typically range from 1 to 7 years. Implementations SHOULD support per-deployment configuration of retention periods and provide automated purging of expired evidence records. Liu, et al. Expires 12 December 2026 [Page 15] Internet-Draft OAuth Authorization Evidence June 2026 6.4. Evidence in Token Exchange When a token carrying an evidence claim is used as the subject_token in a Token Exchange request ([RFC8693]), the AS issuing the exchanged token MUST decide how to handle the original evidence. Three strategies are defined: Propagate: Copy the original evidence claim into the new token. This preserves the direct link to the original user consent. The original AS signature remains valid because the evidence fields are not re-signed. This strategy is RECOMMENDED when the exchanged token's scope is a subset of the original token's scope. When the exchanging AS is different from the original AS, the exchanging AS MUST verify the original as_signature before propagating, and MAY re-sign the evidence with its own key to establish a direct trust chain with the target RS. Reference: Replace the embedded evidence object with an audit_trail claim containing only the evidence_ref pointing to the original evidence record. This reduces token size while maintaining traceability. Implementations using this strategy MUST ensure the referenced evidence record is retrievable by the target RS (e.g., via introspection). Omit: Do not include evidence in the exchanged token. This is appropriate only when the exchanged token's scope does not require consent evidence (e.g., service-to-service calls within the originally authorized boundary). When using the Propagate strategy with delegation chains ([I-D.liu-oauth-chain-delegation]), the root_evidence_ref in the delegation chain entry SHOULD reference the same evidence record, creating an unbroken audit trail from the original user consent through all delegation hops. 6.5. Evidence in Token Refresh When an access token carrying an evidence claim expires and the client obtains a new access token using a refresh token, the AS MUST decide whether to include evidence in the refreshed token. The same three strategies defined in Section 6.4 (Propagate, Reference, Omit) apply, with the following additional considerations: * The user_confirmation.timestamp in the propagated evidence reflects the original consent time, which may be significantly earlier than the refreshed token's iat claim. The RS SHOULD evaluate evidence freshness (Section 8) against the original consent time, not the refresh time. Liu, et al. Expires 12 December 2026 [Page 16] Internet-Draft OAuth Authorization Evidence June 2026 * If the refresh request narrows the token's scope, the Propagate strategy is RECOMMENDED to maintain the audit trail. If the refresh request broadens the scope beyond what the original consent covered, the AS MUST NOT propagate the evidence and SHOULD initiate a new consent interaction instead. * When the refresh token itself was issued alongside the original access token, the evidence record remains valid for the lifetime of the refresh token. The AS SHOULD retain the evidence record (per the Storage Requirements) for at least as long as any refresh token that references it. 7. Resource Server Processing 7.1. Evidence Verification Resource Servers MAY verify the evidence claim by: 1. Extracting the as_signature from the evidence; 2. Verifying the signature using the AS's public key; 3. Confirming that the evidence id and timestamp are consistent with the token's iat claim (i.e., the user confirmation occurred before or at token issuance); 4. Checking the timestamp is within acceptable bounds based on the deployment's evidence freshness policy. Note: The displayed_content field records what was shown to the user during consent. The RS typically does not have direct knowledge of the consent interaction and therefore cannot independently verify this field. Instead, the RS relies on the AS signature as proof that the AS witnessed the user's consent to the described operation. 7.2. Audit Logging Resource Servers SHOULD log evidence information for audit purposes, including: * Evidence ID; * User confirmation timestamp; * Displayed content summary; * Operation performed; Liu, et al. Expires 12 December 2026 [Page 17] Internet-Draft OAuth Authorization Evidence June 2026 * Outcome (success/failure). 8. Security Considerations This section discusses security considerations specific to authorization evidence in OAuth 2.0. General OAuth 2.0 security considerations, including token threats and countermeasures, are described in [RFC6819]. 8.1. Signature Verification The AS signature over the evidence fields (id and user_confirmation) is critical for evidence integrity. Implementations MUST: * Use strong cryptographic algorithms (e.g., RS256, ES256); * Protect AS signing keys appropriately; * Rotate keys periodically with proper key management. 8.2. Evidence Tampering and Trust in the AS The evidence claim is protected by the access token's signature. However, the as_signature field provides an additional layer of protection specifically for the user confirmation record. It is important to understand the trust boundary of the evidence mechanism: the as_signature provides cryptographic proof that the AS *recorded* a user confirmation. It does not independently prove that the user *actually* consented. The AS controls both the consent interaction and the signing key, so a compromised or malicious AS could fabricate evidence records. Trust in the evidence record therefore depends on trust in the AS and its operational security. Deployments requiring stronger non-repudiation guarantees SHOULD supplement this mechanism with user-side signatures or independent consent auditing. 8.3. Replay Attacks Evidence records are bound to specific access tokens. The evidence ID and timestamp help detect attempts to reuse evidence across different authorization contexts. 8.4. Token Size Considerations Including evidence and audit_trail claims increases access token size. Implementations SHOULD consider: Liu, et al. Expires 12 December 2026 [Page 18] Internet-Draft OAuth Authorization Evidence June 2026 * HTTP header size limits when tokens are passed in Authorization headers; * Using token introspection [RFC7662] to retrieve evidence details rather than embedding all data in the token; * Limiting displayed_content length to essential information. 8.5. Token-Evidence Binding The evidence claim is embedded in a signed access token ([RFC9068]), which provides integrity protection at the token level. The inner as_signature provides a second, independent integrity layer specifically over the user confirmation record. This dual-signature design ensures that: * Evidence cannot be moved from one token to another without detection (the token signature would not cover the new evidence); * Evidence fields cannot be modified within a valid token (the inner AS signature would be invalidated); * Evidence can be independently verified even when extracted from the token (e.g., via introspection) using the as_signature. Implementations MUST NOT copy an evidence claim from one access token into another without re-validating the as_signature and confirming that the evidence id and timestamp are consistent with the new token's context. The dual-signature design described above applies to signed JWT access tokens ([RFC9068]). When opaque (reference) tokens are used, the evidence claim is not embedded in the token itself and MUST be retrieved by the RS via token introspection ([RFC7662]) or a dedicated evidence retrieval endpoint. In this case, the as_signature provides the sole integrity protection for the evidence record, and implementations MUST ensure that the transport between the RS and the introspection or retrieval endpoint is protected with TLS. 8.6. Evidence Freshness An evidence record captures user consent at a specific point in time. Deployments SHOULD define an evidence freshness policy that specifies: * The maximum acceptable age of an evidence record (measured from the user_confirmation.timestamp to the current time); Liu, et al. Expires 12 December 2026 [Page 19] Internet-Draft OAuth Authorization Evidence June 2026 * Whether evidence freshness is evaluated relative to the token's iat claim or the current request time; * Actions to take when evidence is stale (e.g., reject the request, require re-consent). For high-sensitivity operations (e.g., financial transactions), a short freshness window (e.g., minutes) is RECOMMENDED. For lower- sensitivity operations, a longer window (e.g., hours) may be acceptable. 8.7. Cross-Domain Evidence Verification In cross-domain scenarios where the RS is in a different trust domain than the AS, the RS must be able to verify the as_signature using the AS's public key. Implementations SHOULD: * Publish the AS's evidence signing keys at a well-known JWKS endpoint ([RFC7517]) accessible to the RS; * Include a kid (Key ID) in the JWS header of the as_signature to enable key selection; * Support key caching at the RS with appropriate cache invalidation to balance performance and key freshness. When the AS and RS belong to different administrative domains, trust establishment for the evidence signing key MAY be facilitated through a trust framework, federation agreement, or explicit key distribution mechanism. 9. Privacy Considerations The privacy considerations in this section are informed by the Internet protocol privacy analysis framework described in [RFC6973]. 9.1. Displayed Content The displayed_content field may contain sensitive information about the user's intent. Implementations SHOULD: * Minimize information in displayed_content to what is necessary; * Avoid including personal data unless required; * Consider encryption for highly sensitive content. Liu, et al. Expires 12 December 2026 [Page 20] Internet-Draft OAuth Authorization Evidence June 2026 9.2. Evidence Retention Evidence records may be subject to data protection regulations. Implementations MUST: * Define retention periods appropriate to regulatory requirements; * Provide mechanisms for evidence deletion when required; * Limit access to evidence records to authorized parties. 9.3. Right to Erasure and Audit Retention Data protection regulations such as GDPR and CCPA grant individuals the right to request deletion of their personal data. Evidence records, which may contain displayed_content reflecting user intent, can constitute personal data. However, evidence records also serve as audit artifacts required by financial, healthcare, and other regulated industries. Implementations SHOULD resolve this tension by: * Minimizing personal data in evidence fields at creation time (e.g., using operation identifiers rather than natural-language descriptions that may contain PII); * Defining separate retention policies for the evidence record (which may be retained longer for audit) and the personal data within it (which may need to be redacted earlier). Note on redaction and signature integrity: The as_signature covers the id and user_confirmation fields as an inseparable unit. Redacting any field within these objects (e.g., removing displayed_content) invalidates the as_signature. Implementations that require redaction of personal data from evidence records SHOULD use the Reference strategy defined in Section 6.4 (Evidence in Token Exchange): issue tokens that carry only an audit_trail claim with the evidence_ref, and perform redaction in the AS's evidence store. The RS then retrieves the (potentially redacted) evidence record via token introspection ([RFC7662]) rather than reading it directly from the token. 10. IANA Considerations 10.1. JWT Claims Registration This specification registers the following claims in the "JSON Web Token Claims" registry: Liu, et al. Expires 12 December 2026 [Page 21] Internet-Draft OAuth Authorization Evidence June 2026 Claim Name: evidence Claim Description: User confirmation evidence with AS signature for authorization proof and audit purposes. Change Controller: IETF Specification Document: 3 of this document Claim Name: audit_trail Claim Description: Semantic traceability metadata linking user intent to authorized operations. Change Controller: IETF Specification Document: 4 of this document 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . Liu, et al. Expires 12 December 2026 [Page 22] Internet-Draft OAuth Authorization Evidence June 2026 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . 11.2. Informative References [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, . Liu, et al. Expires 12 December 2026 [Page 23] Internet-Draft OAuth Authorization Evidence June 2026 [I-D.liu-oauth-rego-policy] Liu, D., "Rego Policy Language for OAuth 2.0", Work in Progress, Internet-Draft, draft-liu-oauth-rego-policy-00, June 2026, . [I-D.liu-oauth-chain-delegation] Liu, D., "Chain Delegation for OAuth 2.0", Work in Progress, Internet-Draft, draft-liu-oauth-chain- delegation-01, June 2026, . [I-D.parecki-oauth-jwt-grant-interaction-response] Parecki, A., Campbell, B., and D. Liu, "JWT Authorization Grant with Interaction Response", Work in Progress, Internet-Draft, draft-parecki-oauth-jwt-grant-interaction- response-00, June 2026, . [I-D.ietf-oauth-identity-assertion-authz-grant] Ying, K. and B. Campbell, "OAuth 2.0 Identity Assertion Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-assertion-authz-grant, January 2026, . Appendix A. Complete Example The following shows a complete access token with both evidence and audit_trail claims: This example also illustrates how the evidence claim complements the rego_policy authorization data type ([I-D.liu-oauth-rego-policy]). While the Rego policy defines *what operations are permitted* (the behavioral constraint contract), the evidence claim records *why those operations were authorized* (the user's explicit consent). Together, they enable a Resource Server to enforce fine-grained policy while maintaining a verifiable audit trail linking each authorized action back to user intent. The act.sub value uses the wit:// URI scheme to identify the acting agent by its workload identity, as defined in the Identity Assertion Authorization Grant ([I-D.ietf-oauth-identity-assertion-authz-grant]). The hash suffix provides a collision-resistant binding between the URI and the agent's attestation evidence. Liu, et al. Expires 12 December 2026 [Page 24] Internet-Draft OAuth Authorization Evidence June 2026 { "iss": "https://as.example.com", "sub": "user_12345", "aud": "https://api.shop.example", "exp": 1731369540, "iat": 1731320700, "jti": "urn:uuid:token-abc-123", "act": { "sub": "wit://myassistant.example/sha256.abc123..." }, "evidence": { "id": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6", "user_confirmation": { "displayed_content": "Add items under $50 to cart", "user_action": "confirmed_via_button_click", "timestamp": 1731320595 }, "as_signature": "eyJhbGciOiJFUzI1NiJ9..MEUCIQDx..." }, "audit_trail": { "evidence_ref": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6", "semantic_expansion_level": "medium", "proposal_ref": "urn:uuid:proposal-xyz" }, "authorization_details": [ { "type": "rego_policy", "policy": { "type": "rego", "uri": "https://as.example.com/policies/policy-cart-50", "entry_point": "allow" } } ] } Figure 5 Acknowledgments The authors would like to thank Brian Campbell for his valuable feedback and insightful discussions during the development of this specification. His contributions helped shape key design decisions. Liu, et al. Expires 12 December 2026 [Page 25] Internet-Draft OAuth Authorization Evidence June 2026 Authors' Addresses Dapeng Liu Alibaba Group Email: max.ldp@alibaba-inc.com Hongru Zhu Alibaba Group Email: hongru.zhr@alibaba-inc.com Suresh Krishnan Cisco Email: suresh.krishnan@gmail.com Aaron Parecki Okta Email: aaron@parecki.com Liu, et al. Expires 12 December 2026 [Page 26]