Authentication Component for Anonymous Token Verification

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Conventional user authentication mechanisms, such as X.509 certificates, require disclosure of private information to verify security token validity, making them vulnerable to counterfeiting and unsuitable for online use, especially when revoking tokens is necessary without exposing confidential data.

Innovation Solution

An authentication service employs a blacklist/whitelist authority using unique user identifiers to generate security tokens, allowing anonymous verification by determining membership or non-membership in revoked or valid token groups without disclosing attribute information, utilizing cryptographic principles and bilinear pairings for secure token management.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If conventional authentication mechanisms (X.509 certificates) are used to verify security token validity, then authentication can be performed, but private information must be disclosed making the system vulnerable to counterfeiting and identity theft

Engineering Contradiction:

Improveauthentication securityVSAvoidprivate information disclosure

Core Design Contradiction:

ReliabilityVSLoss of information

Solution Approach 1:

The authentication system is segmented into multiple independent components: the authentication service that issues tokens, the blacklist/whitelist authority that maintains revocation lists, and the verification mechanism that checks tokens. This segmentation allows each component to perform its function without exposing private information, as the verification only requires checking against public lists rather than disclosing user attributes.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The blacklist/whitelist authority acts as an intermediary between the authentication service and the verification process. Instead of directly comparing security tokens with user attribute data (which would require disclosing private information), the system uses this intermediary to maintain public lists of revoked and valid tokens, enabling verification without information disclosure.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Reliability

If security tokens are revoked to stop unauthorized use, then security is improved, but the revocation process requires disclosing attribute information in conventional systems

Engineering Contradiction:

Improvetoken revocation securityVSAvoidattribute information disclosure

Core Design Contradiction:

ReliabilityVSLoss of information

Solution Approach 1:

The patent extracts the revocation information from the security token itself and stores it separately in the blacklist/whitelist authority. When a token needs to be revoked, only the token identifier is added to the blacklist, not the user's attribute information. This extraction allows revocation to occur without exposing any private data, as the blacklist contains only public token identifiers.

Inventive Principle:

Principle #2Taking out (Extraction)

Solution Approach 2:

Instead of modifying or disclosing the original security token or user attributes during revocation, the system creates a copy of the token identifier and stores it in the blacklist. This copying mechanism allows the system to track revoked tokens without exposing the underlying attribute information that generated the original token.

Inventive Principle:

Principle #26Copying

3Loss of information

If anonymous verification is implemented to protect user privacy, then information disclosure is reduced, but verifying token validity becomes more complex

Engineering Contradiction:

Improveinformation disclosureVSAvoidverification mechanism complexity

Core Design Contradiction:

Loss of informationVSDevice complexity

Solution Approach 1:

The blacklist and whitelist are pre-populated with token identifiers before verification is needed. The authentication service proactively issues tokens and the authority maintains updated lists of valid and revoked tokens in advance. This preliminary action simplifies the verification process, as the verifier only needs to check whether a token identifier exists in the pre-computed lists, rather than performing complex analysis during verification.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The blacklist/whitelist authority performs multiple functions: it maintains the blacklist of revoked tokens, maintains the whitelist of valid tokens, and provides the verification mechanism. This multi-functionality reduces overall system complexity by consolidating what would otherwise require separate components for each function, while still maintaining anonymous verification.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentUS10623398B2Verifying requests for access to a service provider using an authentication component

Publication Date: 2020.04.14 MICROSOFT TECHNOLOGY LICENSING LLC

AI summary

The subject disclosure is directed towards processing requests for accessing a service provider. After examining at least one security token, a public key and a portion of attribute information are identified. An authentication component is accessed and applied to the public key. A unique user identifier is employed in generating the public key. The authentication component is generated using information from at least one revoked security token or at least one valid security token. The authentication component is configured to prove validity of the at least one security token.