Complex Composite Tokens for Traceable Multi-Partner OAuth Delegation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing OAuth token sharing methods introduce security risks and limit auditability due to impersonation and lack of clear identity tracking, particularly in complex transaction scenarios involving multiple partners, such as those requiring PCI DSS or HIPPA compliance.

Innovation Solution

Implement a trust stack system using complex composite tokens that maintain a chain of trust between multiple entities, allowing for granular permission control and auditability by linking entities through a trust stack maintained by an OAuth server.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If OAuth tokens are shared among multiple partners for transaction processing, then transaction functionality is enabled across partners, but security risks increase and auditability is lost due to impersonation

Engineering Contradiction:
Improvetransaction functionalityVSAvoidsecurity and auditability
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent segments the OAuth token into two distinct parts: a subject token containing the original client's credentials and an actor token containing the partner's credentials. This segmentation allows each token to maintain its own identity and permissions, enabling secure multi-partner transactions while preserving security and auditability through distinct token validation.

Inventive Principle:
Principle #1Segmentation

2Ease of operation

If a partner impersonates a customer using the customer's OAuth token, then the partner can access customer resources, but the customer's identity cannot be traced in the transaction

Engineering Contradiction:
Improveresource accessVSAvoididentity traceability
Core Design Contradiction:
Ease of operationVSLoss of information

Solution Approach 1:

The patent introduces an intermediary mechanism where the OAuth server acts as a mediator between the customer and partner. The server validates both the subject token and actor token, creating a trusted relationship without requiring direct impersonation. This intermediary approach enables resource access while maintaining identity traceability through the OAuth server's validation and logging.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Reliability

If compliance standards like PCI DSS or HIPPA are implemented directly, then security is improved, but implementation complexity and cost increase

Engineering Contradiction:
Improvesecurity complianceVSAvoidimplementation complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent uses the OAuth server as an intermediary that handles compliance requirements centrally. Rather than requiring each partner to implement complex compliance measures, the OAuth server validates tokens and enforces security policies, simplifying implementation while maintaining compliance. The server acts as a trusted intermediary that manages security complexity on behalf of multiple partners.

Inventive Principle:
Principle #24Intermediary (Mediator)

4Ease of manufacture

If traditional token sharing is used, then integration between partners is simplified, but security risks and compliance burdens are transferred to each partner

Engineering Contradiction:
Improveintegration simplicityVSAvoidcompliance burden
Core Design Contradiction:
Ease of manufactureVSDevice complexity

Solution Approach 1:

The patent segments the authentication process into distinct token validation steps handled by the OAuth server. The subject token and actor token are validated separately, with the server managing compliance requirements centrally. This segmentation maintains integration simplicity for partners while centralizing compliance management, reducing the compliance burden on individual partners.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentEP3932031B1Complex composite tokens
Publication Date: 2025.08.13 EBAY INC
  • EP3932031B1 patent drawingFigure 1
  • EP3932031B1 patent drawingFigure 2A
  • EP3932031B1 patent drawingFigure 2B

AI summary

Technologies are shown for trust delegation that involve receiving a first request from a subject client and responding by sending a first token having first permissions to the subject client. A second request from a first actor includes the first token and responding involves linking the first actor to the subject client in a trust stack and sending a second token to the first actor with second permissions, the second token being a first complex token that identifies the subject client and the first actor. A third request from a second actor includes the second token and responding to the third request involves linking the second actor to the first actor in the trust stack, and sending a third token to the second actor partner with third permissions, the third token being a second complex token that identifies the first actor and the second actor.