Authorization Evidence and Audit Trail for OAuth 2.0 Access Tokens

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.¶

3.1. Claim Definition

Claim Name:

evidence¶

Claim Type:

Object¶

Usage:

Access tokens¶

3.2. Structure

{
  "evidence": {
    "id": "evidence-abc123",
    "user_confirmation": {
      "displayed_content": "Add items under $50 to cart",
      "user_action": "confirmed_via_button_click",
      "timestamp": 1731320595,
      "interface_version": "consent-ui-v2.1"
    },
    "session_context": {
      "session_id": "session_xyz789",
      "client_instance": "dfp_abc123",
      "channel": "mobile-app"
    },
    "as_signature": "eyJhbGciOiJSUzI1NiIs..."
  }
}

3.3. Field Definitions

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;¶
• Enables non-repudiation for dispute resolution.¶

The signature MUST be computed over the following fields of the evidence object:¶

• id¶
• user_confirmation (entire object)¶
• session_context (if present)¶

The as_signature field itself MUST be excluded from the signature computation. The signature input MUST be constructed using JSON Canonicalization Scheme (JCS) as defined in RFC 8785 to ensure deterministic serialization. The signature format MUST be a detached JWS (JSON Web Signature) using the AS's signing key.¶

4.1. Claim Definition

Claim Name:

audit_trail¶

Claim Type:

Object¶

Usage:

Access tokens¶

4.2. Structure

{
  "audit_trail": {
    "evidence_ref": "evidence-abc123",
    "semantic_expansion_level": "medium",
    "interpretation_notes": "Mapped 'cheap' to '$50 limit'",
    "proposal_ref": "urn:uuid:proposal-xyz"
  }
}

4.3. Field Definitions

4.4. Semantic Expansion Levels

The semantic_expansion_level field indicates how much the system interpreted or expanded the user's original intent:¶

none:

No interpretation; user specified exact parameters.¶

low:

Minor defaults applied (e.g., default quantity of 1).¶

medium:

Significant interpretation (e.g., "cheap" mapped to "$50").¶

high:

Substantial expansion (e.g., multi-step plan derived from goal).¶

6.1. 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 user_confirmation object with the AS's private key;¶
5. Include the evidence claim in the access token.¶

6.2. 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.¶

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 the displayed_content matches the requested operation;¶
4. Checking the timestamp is within acceptable bounds.¶

7.2. Audit Logging

Resource Servers SHOULD log evidence information for audit purposes, including:¶

• Evidence ID;¶
• User confirmation timestamp;¶
• Displayed content summary;¶
• Operation performed;¶
• Outcome (success/failure).¶

8.1. Signature Verification

The AS signature over 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

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.¶

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.¶

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.¶

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.¶

10.1. JWT Claims Registration

This specification registers the following claims in the "JSON Web Token Claims" registry:¶

Claim Name:

evidence¶

Claim Description:

User confirmation evidence with AS signature for authorization proof and audit purposes.¶

Change Controller:

IETF¶

Specification Document:

Section 3 of this document¶

Claim Name:

audit_trail¶

Claim Description:

Semantic traceability metadata linking user intent to authorized operations.¶

Change Controller:

IETF¶

Specification Document:

Section 4 of this document¶