Capability-Carrying Access Tokens for Proactive Rejection Handling

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing systems lack efficient methods for entities to communicate capability information to identity and resource providers, leading to inefficient handling of access token rejections due to reasons other than expiration, such as policy changes or environmental conditions.

Innovation Solution

A computing system that allows entities to indicate capability information in access tokens, enabling resource providers to enforce policies based on these capabilities, facilitating immediate session termination and reauthentication when necessary, and allowing direct communication between identity and resource providers for enhanced policy administration.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If entities send repeated requests after access token rejection, then they may eventually gain access, but this causes unnecessary retries and increases system load and time consumption

Engineering Contradiction:
Improveaccess token rejection handlingVSAvoidretry time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs preliminary action by including capability information in the access token before resource access attempts. This capability information enables the resource provider to make informed decisions about token rejection, allowing entities to take appropriate actions (such as stopping retries) without wasting time on unsuccessful attempts.

Inventive Principle:
Principle #10Preliminary action

2Ease of operation

If centralized policy management is implemented at the identity provider, then policy administration is simplified, but the system lacks granularity in enforcing specific policies at resource providers

Engineering Contradiction:
Improvepolicy administrationVSAvoidpolicy enforcement granularity
Core Design Contradiction:
Ease of operationVSAdaptability or versatility

Solution Approach 1:

The system segments policy information into two parts: centralized policy definitions stored at the identity provider, and capability information embedded in access tokens that can be evaluated by resource providers. This segmentation allows centralized management while enabling granular enforcement at the resource level.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The access token acts as an intermediary carrying capability information from the identity provider to the resource provider. This intermediary mechanism enables policy information to be transmitted and enforced at the resource level without requiring direct communication or complex configuration between the identity provider and resource providers.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Reliability

If entities do not communicate capability information, then the system is simpler, but the system cannot efficiently handle access token rejections or enforce capability-based policies

Engineering Contradiction:
Improvepolicy enforcementVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The access token serves multiple functions: it provides authentication credentials and simultaneously carries capability information. This multi-functionality allows the system to enforce capability-based policies without adding separate communication channels or data structures, thereby limiting the increase in system complexity.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentEP4052151B1Client readiness system
Publication Date: 2025.09.17 MICROSOFT TECHNOLOGY LICENSING LLC
  • EP4052151B1 patent drawingFigure 1
  • EP4052151B1 patent drawingFigure 2
  • EP4052151B1 patent drawingFigure 3~4

AI summary

A computing system configured to support entities having the ability to indicate capability information for capabilities of the entities is illustrated. Embodiments may include an identity provider computer system comprising at least one processor. The identity provider computer system is configured to receive requests for access tokens from entities. The requests include capability information for the entities. The identity provider computer system is further configured to provide access tokens to the entities which include the capability information. The computing system further includes a resource provider computer system comprising at least one processor configured to receive resource requests and access tokens from entities. The access tokens include the capability information. The resource providers are further configured to provide responses to the entities according to the capability information.