Pseudonymous Alias Authentication for Privacy-Preserving SSO

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional single sign-on (SSO) systems either infringe user privacy by sharing unique identities across service providers or require complex identity federation mechanisms that still risk database cross-referencing, lacking sufficient privacy protection.

Innovation Solution

A method for single authentication that involves a preliminary identity federation phase where a user generates and masks an alias, allowing the identity provider to associate a masked alias with their identity, and the user calculates and transmits a signature for authentication, ensuring that service providers cannot cross-reference customer databases.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If a unique local identity is shared by the Identity Provider and Service Providers, then single sign-on functionality is achieved, but user privacy is infringed as databases can be cross-referenced

Engineering Contradiction:
Improvesingle sign-on functionalityVSAvoiduser privacy infringement
Core Design Contradiction:
Ease of operationVSObject-affected harmful factors

Solution Approach 1:

The patent segments the user identity into multiple components: a stable unique identifier stored only at the IdP, and dynamic pseudonymous identifiers (aliases) used for authentication with SPs. This segmentation allows SSO functionality while preventing database cross-referencing, as the SPs only see aliases without the ability to link them to the user's true identity or to each other.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces pseudonymous aliases as intermediaries between the user's true identity and the service providers. These aliases act as mediators that enable authentication and SSO while blocking the direct link between user identity and SP databases, thus protecting user privacy while maintaining operational ease.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Object-affected harmful factors

If identity federation is implemented with federation aliases, then user privacy is protected, but the system complexity increases due to correspondence tables and alias management

Engineering Contradiction:
Improveuser privacy protectionVSAvoididentity federation mechanism complexity
Core Design Contradiction:
Object-affected harmful factorsVSDevice complexity

Solution Approach 1:

The patent extracts the complex correspondence table management from the system by eliminating the need for SPs to maintain aliases. Only the IdP stores and manages the mapping between unique identifiers and aliases, significantly reducing system complexity while maintaining privacy protection.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent discards the traditional federation alias mechanism that requires complex correspondence tables at both IdP and SP. Instead, it recovers a simplified model where only the IdP maintains minimal mapping information, and SPs work directly with unique identifiers through cryptographic proofs, reducing overall system complexity.

Inventive Principle:
Principle #34Discarding and recovering

3Reliability

If the Identity Provider provides federation aliases to Service Providers, then authentication is enabled, but the Identity Provider possesses information that allows cross-referencing customer databases

Engineering Contradiction:
Improveauthentication functionalityVSAvoiddatabase cross-referencing capability
Core Design Contradiction:
ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The patent uses pseudonymous aliases as intermediaries that the IdP generates and controls. These aliases enable authentication functionality while the IdP's control over alias generation and the cryptographic nature of the protocol prevent the IdP from being able to cross-reference SP databases, as the aliases do not contain direct links to user identities or SP-specific information.

Inventive Principle:
Principle #24Intermediary (Mediator)

4Productivity

If conventional SSO mechanisms are used, then authentication efficiency is improved, but they lack sufficient privacy protection mechanisms

Engineering Contradiction:
Improveauthentication efficiencyVSAvoidprivacy protection insufficiency
Core Design Contradiction:
ProductivityVSObject-affected harmful factors

Solution Approach 1:

The patent replaces traditional mechanical identity sharing mechanisms with cryptographic protocols. Instead of directly sharing identities or relying on trust-based mechanisms, the system uses cryptographic proofs, hashed identifiers, and pseudonymous aliases that maintain authentication efficiency while inherently providing privacy protection through mathematical security rather than procedural controls.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

Data Source

PatentEP2116000B1Method for the unique authentication of a user by service providers
Publication Date: 2017.05.17 ORANGE SA
  • EP2116000B1 patent drawingFigure 1~2
  • EP2116000B1 patent drawingFigure 3
  • EP2116000B1 patent drawingFigure 4

AI summary

The invention relates to a method for the unique authentication of a user (U) by at least one service provider (SP), said method comprising the preliminary phase of federating identities between an identity (user@sp) of the user by said service provider and an identity (user@idp) of the user (U) by an identity provider (IdP). According to the invention, the preliminary identity federation phase comprises the following steps: for the user (U), generating an alias ([alias]) of the user for the service provider (SP) and transmitting to the identity provider (IdP) a masked alias ([alias]masqué) derived from the alias; for the identity provider (IdP), associating said masked alias ([alias]masqué) for this service provider (SP) with the user's identity (user@idp) by the identity provider (IdP), and transmitting elements to the user (U) so that the user can calculate a signature ( s ) of a message {msg) containing the unmasked alias ([alias]); for the user (U), calculating said signature ( s ) and transmitting to the service provider (SP) said message {msg) with said signature ( s ); and for the service provider (SP), checking said signature ( s ), authenticating the user (U) and associating said alias ([alias]) with the user's identity (user@sp) by the service provider (SP).