Token Revocation Status Segmentation for Privacy

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing security management systems compromise user privacy by requiring service providers to maintain blacklists or whitelists of token revocation status, allowing potential data linkage and collusions that endanger user anonymity.

Innovation Solution

A security management system where tokens possess a status attribute indicating revocation status, managed by a revocation management terminal that updates and verifies this attribute without propagating blacklists, ensuring that service providers cannot link user identities or collude.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If specific blacklists are maintained for each service provider to track revoked tokens, then security management is improved, but user privacy is compromised due to data linkage possibilities

Engineering Contradiction:

Improvesecurity managementVSAvoiduser privacy compromise

Core Design Contradiction:

ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The system segments the revocation status verification by creating separate status attributes for each service provider terminal in the token. This allows each service provider to independently verify revocation status without sharing data with other service providers, thereby maintaining security while preserving user privacy through data segmentation.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The token itself acts as an intermediary that stores and presents revocation status information to service providers. Instead of service providers directly accessing a centralized blacklist, the token mediates the verification process by providing its own status attribute, preventing direct data linkage between service providers.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Reliability

If specific blacklists are propagated to all service providers, then revocation status verification is improved, but system complexity increases due to list management

Engineering Contradiction:

Improverevocation status verificationVSAvoidlist management complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The token performs self-service by maintaining its own revocation status attributes for different service providers and autonomously presenting the appropriate status to each service provider terminal. This eliminates the need for complex centralized list management and propagation, as each token independently manages its own status information.

Inventive Principle:

Principle #25Self-service

3Ease of operation

If service providers access centralized token lists, then revocation verification is simplified, but user anonymity is endangered through potential collusion

Engineering Contradiction:

Improverevocation verificationVSAvoiduser anonymity risk

Core Design Contradiction:

Ease of operationVSObject-affected harmful factors

Solution Approach 1:

The revocation status is segmented into separate status attributes for each service provider terminal within the token. This segmentation ensures that when a service provider verifies the token status, it only receives information relevant to that specific provider, preventing collusion-based linkage and preserving user anonymity while maintaining operational simplicity.

Inventive Principle:

Principle #1Segmentation

4Reliability

If centralized tracking of token revocation is implemented, then security control is improved, but data linkage between service providers becomes possible

Engineering Contradiction:

Improvesecurity controlVSAvoiduser privacy information

Core Design Contradiction:

ReliabilityVSLoss of information

Solution Approach 1:

The system implements local quality by storing service provider-specific revocation status attributes directly within each token. This allows security control to be maintained locally at the token level for each service provider relationship, preventing the centralization of tracking information that would enable data linkage and privacy loss.

Inventive Principle:

Principle #3Local quality

Data Source

PatentEP3178073B1Security management system for revoking a token from at least one service provider terminal of a service provider system

Publication Date: 2023.06.28 THALES DIS FRANCE SA

Figure 1
Figure 2
Figure 3~4

AI summary

The present invention relates to a security management system (SYS) comprising a plurality of tokens (SE), a revocation management system (RM_SYS) and a service provider system (SP_SYS) comprising at least one service provider terminal (SP_T), wherein: - each token (SE) comprises at least one status attribute (R), said at least one status attribute (R) indicating if a token (SE) is revoked or not from at least one service provider terminal (SP_T) of said service provider system (SP_SYS); - said revocation management system (RM_SYS) comprises a revocation management terminal (RM_T), said revocation management terminal (RM_T) comprising a token status list (Lr) which comprises first data (D1) corresponding to the tokens (SE) which are revoked or corresponding to the tokens (SE) which are not revoked, and said revocation management terminal (RM_T) being adapted to : - read said first data (D1) from a token (SE); - check said first data (D1) against the token status list (Lr); - update the at least one status attribute (R) of said token (SE) according to said checking; - said service provider terminal (SP_T) is adapted to verify if a token (SE) is revoked from it, or not, said verification being based on the at least one status attribute (R) of said token (SE).